From: Daniel Phillips <email@example.com> To: Rik van Riel <firstname.lastname@example.org> Cc: Andrew Morton <email@example.com>, Lorenzo Allegrucci <firstname.lastname@example.org>, Linux Kernel <email@example.com> Subject: Re: qsbench, interesting results Date: Tue, 1 Oct 2002 19:03:40 +0200 [thread overview] Message-ID: <E17wQQv-0005vB-00@starship> (raw) In-Reply-To: <Pine.LNX.4.44L.firstname.lastname@example.org> On Tuesday 01 October 2002 18:52, 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 ... No it's not, it's very similar to having several processes active whose working sets add up to more than RAM. > > The page replacement algorithm ought to do something sane with it, > > ... page replacement ought to give this process less RAM > because it isn't going to get enough to run anyway. No need > to have a process like qsbench make other processes run > slow, too. It should run the process as efficiently as possible, given that there isn't any competition. > > and swap performance ought to be decent in general, since desktop users > > typically have less than 1/2 GB. With media apps, bloated desktops and > > all, it doesn't go as far as it used to. > > The difference there is that desktops don't have a working > set larger than RAM. They've got a few (dozen?) of processes, > each of which has a working set that easily fits in ram and > a bunch of pages, or whole processes, which aren't currently > in use. Try loading a high res photo in gimp and running any kind of interesting script-fu on it. If it doesn't thrash, boot with half the memory and repeat. > In this situation the VM _can_ keep the whole working set in > RAM, simply by evicting the stuff that's not in the working > set. We're not talking about that case. Oh, by the way, since when did it become ok to ignore corner cases? I thought corner cases were what users have been flaming us about for the last 2 or 3 years. > > My impression is that page replacement just hasn't gotten a lot of > > attention recently, and there is nothing wrong with that. It's tuning, > > not a feature. > > As you write above, it's a pretty damn important feature, > though. One thing I'm experimenting with now for 2.4 rmap > is to ignore the referenced bit and page age if a page is > only in use by processes which haven't run recently, this > should help the desktop (and university) workloads by > swapping out memory from tasks which don't need it anyway > at the moment. > > There may be other modifications needed, too... No doubt, and for the first time, we've got a solid base to build on. -- Daniel
next prev parent reply other threads:[~2002-10-01 17:02 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 [this message] 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 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=E17wQQv-0005vB-00@starship \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --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).