From: Andrea Arcangeli <andrea@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-kernel@vger.kernel.org, rohit.seth@intel.com
Subject: Re: kiobuf wrong changes in 2.4.9ac9
Date: Thu, 6 Sep 2001 15:59:22 +0200 [thread overview]
Message-ID: <20010906155921.F11329@athlon.random> (raw)
In-Reply-To: <20010906030228.C11329@athlon.random> <E15eyI5-00080I-00@the-village.bc.nu>
In-Reply-To: <E15eyI5-00080I-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Thu, Sep 06, 2001 at 01:29:53PM +0100
On Thu, Sep 06, 2001 at 01:29:53PM +0100, Alan Cox wrote:
> > The above is all about performance and design, about real world
> > showstopper the one in 2.4.9ac9 is that kiobuf allocations are going to
> > fail during read/writes due mem framentation (this is why it was using
> > vmalloc indeed) [those faliures should be easily reprocible on x86 boxes
>
> Vmalloc is extremely expensive on many platforms. It looks very easy to
> simple flip between slab and vmalloc based on size.
based on size in turn means based on source because the kiobuf has a
fixed size. This is why I'm saying it has to be vmalloced in these
kernel trees until we shrink it and the plan to shrink it is first of
all to split the io backend out of the memory management part.
> Let me know how the testing goes - if it works out well then I'll migrate
> the -ac tree to the -aa patch when I have time to do the merging
btw, I actually don't have the workload here (my software simulations says
it works but it's not exactly the same workload, the workload I
simulated to test it is pure simultaneous rawio I/O load to the same
rawio device via different filp) so I'd like to know too ;)
Andrea
prev parent reply other threads:[~2001-09-06 13:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-06 1:02 kiobuf wrong changes in 2.4.9ac9 Andrea Arcangeli
2001-09-06 12:29 ` Alan Cox
2001-09-06 13:59 ` Andrea Arcangeli [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=20010906155921.F11329@athlon.random \
--to=andrea@suse.de \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rohit.seth@intel.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