From: "David S. Miller" <davem@redhat.com>
To: alan@lxorguk.ukuu.org.uk
Cc: Ulrich.Weigand@de.ibm.com, zaitcev@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: The IBM order relaxation patch
Date: Wed, 06 Feb 2002 20:01:00 -0800 (PST) [thread overview]
Message-ID: <20020206.200100.85392985.davem@redhat.com> (raw)
In-Reply-To: <E16YcH1-0006ua-00@the-village.bc.nu>
In-Reply-To: <OF5FF19417.595BC760-ONC1256B58.00762715@de.ibm.com> <E16YcH1-0006ua-00@the-village.bc.nu>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Thu, 7 Feb 2002 00:18:47 +0000 (GMT)
> >with a GPF flag? What they describe does not happen in an
> >interrupt context, so we can sleep.
>
> Because nobody even *tries* to free adjacent pages to build up
> a free order-2 area. You could wait really long ...
Without the rmap patch you can't easily do it
One change from Rik's VM (both of them, the 2.4.9 based AC stuff and
RMAP) and the current stuff in Linus's tree is that order 2 and
smaller are treated all equally.
This got rid of a lot of problems on Sparc64 and with AF_UNIX sockets
for example. Sparc64 has the same issue as the IBM patch is trying
to solve, we need order 1 pages for our page table allocations. And
AF_UNIX was trying to use large linear buffers for better performance
during bulk transfers.
Btw, the AF_UNIX side of this results in all kinds of MYSQL
performance problems, or at least this is how I remember it.
(for more details on this grep for SKB_MAX_ALLOC in current
2.4.x/2.5.x sources, in particular the references in
include/linux/skbuff.h and net/unix/af_unix.c)
There was even a linux-kernel thread about all of this back in
the 2.4.{13,14,15} days, perhaps someone can find it on
marc.theaimsgroup.com
I do not think the Linus VM behavior is unreasonable, which basically
amounts to continually trying to free pages for all order 3 and below
allocations (if you can sleep and you aren't PF_MEMALLOC etc.).
> rmap method could help here, because with reverse mappings we
> can at least try to free adjacent areas (because we then at least
> *know* who's using the pages).
rmap definitely makes it a real no brainer to do this at least for small
clusters of pages. Doing large chunks gets progressively harder
You just have to be careful that you don't let the algorithm
degenerate into a dumb scan, which is the kind of silly stuff
the VM used to do back in the pre-2.2.x days :-)
next prev parent reply other threads:[~2002-02-07 4:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-06 21:50 The IBM order relaxation patch Ulrich Weigand
2002-02-07 0:18 ` Alan Cox
2002-02-07 4:01 ` David S. Miller [this message]
2002-02-07 12:16 ` Rik van Riel
2002-02-07 12:29 ` David S. Miller
2002-02-07 12:42 ` Rik van Riel
2002-02-07 12:58 ` Hugh Dickins
2002-02-07 14:12 ` Daniel Phillips
2002-02-07 14:55 ` Rik van Riel
2002-02-07 15:07 ` Daniel Phillips
2002-02-07 15:10 ` David S. Miller
2002-02-09 20:21 ` Alex Bligh - linux-kernel
-- strict thread matches above, loose matches on Subject: below --
2002-02-07 15:05 Ulrich Weigand
2002-02-07 15:13 ` Rik van Riel
2002-02-07 17:57 ` Daniel Phillips
2002-02-06 19:13 Pete Zaitcev
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=20020206.200100.85392985.davem@redhat.com \
--to=davem@redhat.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/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