[lkml]   [2001]   [Sep]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: kiobuf wrong changes in 2.4.9ac9
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 ;)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.028 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site