From: Larry McVoy <email@example.com> To: Rik van Riel <firstname.lastname@example.org> Cc: Daniel Phillips <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Lorenzo Allegrucci <email@example.com>, Linux Kernel <firstname.lastname@example.org> Subject: Re: qsbench, interesting results Date: Tue, 1 Oct 2002 10:15:39 -0700 [thread overview] Message-ID: <20021001101539.F5595@work.bitmover.com> (raw) In-Reply-To: <Pine.LNX.4.44L.email@example.com>; from firstname.lastname@example.org on Tue, Oct 01, 2002 at 01:52:25PM -0300 On Tue, Oct 01, 2002 at 01:52:25PM -0300, Rik van Riel wrote: > On Tue, 1 Oct 2002, Daniel Phillips wrote: > > On Monday 30 September 2002 07:57, Andrew Morton wrote: > > > I'll take a look at some preferential throttling later on. But > > > I must say that I'm not hugely worried about performance regression > > > under wild swapstorms. The correct fix is to go buy some more > > > RAM, and the kernel should not be trying to cater for underprovisioned > > > machines if that affects the usual case. > > > > The operative phrase here is "if that affects the usual case". > > Actually, the quicksort bench is not that bad a model of a usual case, > > i.e., a working set 50% bigger than RAM. > > Having the working set of one process larger than RAM is > a highly unusual case ... "bk -r check -acv" on the linux-2.5 tree shows up as 39MB RSS in top and is actually much bigger, it wants all of the SCCS files in ram to go fast. If they are, it's about 15 seconds on a Ghz box, if they aren't, it's mucho longer. I _think_ we're careful to not go back and look at the same files twice but I might be smoking crack. All I know is that running a check on a 128MB machine is painful as hell. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
next prev parent reply other threads:[~2002-10-01 17:10 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-29 14:15 Lorenzo Allegrucci 2002-09-29 16:26 ` bert hubert 2002-09-29 19:56 ` Lorenzo Allegrucci 2002-09-29 20:00 ` bert hubert 2002-09-29 21:05 ` Lorenzo Allegrucci 2002-09-30 5:57 ` Andrew Morton 2002-10-01 14:05 ` Daniel Phillips 2002-10-01 16:52 ` Rik van Riel 2002-10-01 17:03 ` Daniel Phillips 2002-10-01 17:13 ` Rik van Riel 2002-10-01 17:20 ` Daniel Phillips 2002-10-01 17:29 ` Rik van Riel 2002-10-01 17:38 ` Daniel Phillips 2002-10-01 18:18 ` Lorenzo Allegrucci 2002-10-01 17:15 ` Larry McVoy [this message] 2002-10-01 18:04 ` Andrew Morton 2002-10-01 18:20 ` Rik van Riel 2002-10-01 18:35 ` Daniel Phillips
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=20021001101539.F5595@work.bitmover.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: qsbench, interesting results' \ /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
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 NNTP newsgroup(s).