Re: MM deadlock [was: Re: arca-vm-8...]
Alan Cox (alan@lxorguk.ukuu.org.uk)
Tue, 26 Jan 1999 15:46:23 +0000 (GMT)
> > the toughest part is the 'moving' stuff, which is not yet present and
> > hard/impossible to implement in a clean and maintainable way. We need this
> > eg. for sockets, files, (not inodes fortunately), task structures, vmas,
>
> What's the benefit? If you need big chunks of physical memory, then you
> obviously are willing to sacrifice efficient use of every last byte.
>
> > yes it restricts and complicates the way kernel subsystems can allocate
> > buffers, but we _have_ to do that iff we want to solve the problem 100%.
>
> So for that last 10% of "solve" we introduce a lot of complexity into
> every subsystem?
We don't need to solve the 100% case. Simply being sure we can (slowly)
allocate up to 25% of RAM in huge chunks is going to be enough. Good point
Ingo on one thing I'd missed - the big chunks themselves need some kind
of handles since the moment we hand out 512K chunks we may not be able to
shuffle and get a 4Mb block
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/