From: "Paul E. McKenney" <paulmck@kernel.org>
To: Akira Yokosawa <akiyks@gmail.com>
Cc: perfbook@vger.kernel.org
Subject: Re: [RFT PATCH -perfbook 0/2] Retouch plots in QQA 15.31
Date: Sat, 3 Feb 2024 04:56:20 -0800 [thread overview]
Message-ID: <948e4860-3152-4802-b2cf-a06531150e45@paulmck-laptop> (raw)
In-Reply-To: <6159c720-0a7b-4670-895d-27282486148e@gmail.com>
On Sat, Feb 03, 2024 at 11:12:39AM +0900, Akira Yokosawa wrote:
> On 2024/01/31 5:20, Paul E. McKenney wrote:
> [...]
> >
> > Except that github choked on the 366MB coe.out file. The gzip command
> > compresses it to 72MB, and "tar -cJf" gets it down to 33MB, so maybe I
> > rebase the compressed version into the commit that created that file.
>
> Quote from github's file size limit at:
> https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-large-files-on-github#file-size-limits
>
> GitHub limits the size of files allowed in repositories. If you
> attempt to add or update a file that is larger than 50 MiB, you
> will receive a warning from Git. The changes will still
> successfully push to your repository, but you can consider removing
> the commit to minimize performance impact. For more information,
> see "Removing files from a repository's history."
>
> ...
>
> GitHub blocks files larger than 100 MiB.
>
> You hit the github's limit.
>
> >
> > And change the script that collects the data to do the compression. ;-)
> >
> > Now kernel.org had no problem with the full file, but it might also
> > be good to avoid imposing too much on their storage-space largesse...
> >
> > Other thoughts?
>
> Well, no. Using xz compression looks reasonable to me.
I will need to figure something else out if I ever get access to a system
with (say) 500 CPUs. If nothing else, split it into one compressed file
per CPU. I am sure that github will love that. ;-)
> By the way, you added the following in the answer to QQA 15.31:
>
> Alert readers may have noticed that the distribution shown in
> Figure E.10 is monomodal, which those in Figure E.12 and
> Figure E.14 are trimodal.
>
> In coe.png, whose bin_width is 2 I think, I see a spike around
> time period = [38, 40]. Count of time period 40 is 140 and the
> largest count in coe.dat.
>
> Attached coe.png is the histogram version of the same plot.
> The spike is more evident there.
>
> This spike causes slight but significant enough bump in the
> right shoulder of Figure E.10 whose bin_width is 40.
> You can still say the distribution is monomodal, but I just
> wanted to make sure.
>
> Or I can replace the EPS plot with the one with bin_width=2,
> if you prefer.
Thank you for checking, and please do replace that plot. I will
then reword that text to say something like "almost monomodal" and
"emphatically trimodal".
Thanx, Paul
prev parent reply other threads:[~2024-02-03 12:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 15:31 [RFT PATCH -perfbook 0/2] Retouch plots in QQA 15.31 Akira Yokosawa
2024-01-30 15:33 ` [RFT PATCH -perfbook 1/2] CodeSamples/cpu/data/.../plots.sh: Fix typo in xlabel for fre plot Akira Yokosawa
2024-01-30 15:37 ` [RFT PATCH -perfbook 2/2] CodeSamples/cpu/data: Use "smooth frequency" for plotting histogram Akira Yokosawa
2024-01-30 17:57 ` [RFT PATCH -perfbook 0/2] Retouch plots in QQA 15.31 Paul E. McKenney
2024-01-30 20:20 ` Paul E. McKenney
2024-02-03 2:12 ` Akira Yokosawa
2024-02-03 12:56 ` Paul E. McKenney [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=948e4860-3152-4802-b2cf-a06531150e45@paulmck-laptop \
--to=paulmck@kernel.org \
--cc=akiyks@gmail.com \
--cc=perfbook@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).