public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Aviv Shavit <avivshavit@yahoo.com>
Cc: Ken Brownfield <ken@irridia.com>, linux-kernel@vger.kernel.org
Subject: Re: vm-33, strongly recommended [Re: [2.4.17/18pre] VM and swap - it's really unusable]
Date: Fri, 12 Apr 2002 02:20:46 +0200	[thread overview]
Message-ID: <20020412022046.B31905@dualathlon.random> (raw)
In-Reply-To: <20020411183443.A21005@asooo.flowerfire.com> <20020411235015.78405.qmail@web13203.mail.yahoo.com>

On Thu, Apr 11, 2002 at 04:50:15PM -0700, Aviv Shavit wrote:
> This goes back to my previous post - 
> Applying only the vm patches didn't get me far.
> 
> I'm still trying to pin point what it is thats helping
> me out in -aa

For the level of cache during your workload (you mentioned that variable
in the previous email) what matters mostly is the vm-33 patch. Do you
get significantly different levels of cache with only the vm-33 patch
compared to the whole latest -aa? (there are other variables too that
could influence the level of cache, the readahead boost for example, but
they're much less likely to influence the cache levels than the vm-33
patch)

It maybe the benefit you see is not only in the VM part, but it could
came also the dozen of other fixes and improvements. For example
starting from the lowlatency fixes from Andrew (note: _fixes_) to highio
(from Jens) if you've highmem, to the dyn-sched (from Davide) if you've
tons of sleeping tasks or interactive processes etc...

The reason I maintain the main patches like the vm one also against
mainline, is exactly to address Ken's concern about being able to apply
just one patch if he's not confortable with the whole patchkit, and
secondly to be able to test it separately without the pollution. I feel
the vm patch is one of the most important and that's why I mentioned it
in particular, but the lowlatency fixes and lots of other stuff is
important too. But I've also the feeling the other stuff [modulo the
major things like pte-highmem and highio that at least affects only the
x86 high-end and not that much desktops or little server] is much much
easier to get integrated and that's why I worry much less about it.

Thanks for all the feedback and testing!

Andrea

  reply	other threads:[~2002-04-12  0:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-25 11:51 [2.4.17/18pre] VM and swap - it's really unusable Aviv Shavit
2002-02-26  0:09 ` Ken Brownfield
2002-02-26  4:40   ` Ken Brownfield
2002-04-09 20:45     ` Aviv Shavit
2002-04-09 21:16       ` Rik van Riel
2002-04-09 23:36       ` vm-33, strongly recommended [Re: [2.4.17/18pre] VM and swap - it's really unusable] Andrea Arcangeli
2002-04-10  0:07         ` Richard Gooch
2002-04-10  0:30           ` Andrea Arcangeli
2002-04-10 22:40             ` Richard Gooch
2002-04-10 23:51               ` Andrea Arcangeli
2002-04-10  8:55         ` Christoph Hellwig
2002-04-11 23:34         ` Ken Brownfield
2002-04-11 23:50           ` Aviv Shavit
2002-04-12  0:20             ` Andrea Arcangeli [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-04-10  1:17 shane

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=20020412022046.B31905@dualathlon.random \
    --to=andrea@suse.de \
    --cc=avivshavit@yahoo.com \
    --cc=ken@irridia.com \
    --cc=linux-kernel@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