Re: MM deadlock [was: Re: arca-vm-8...]

Alan Cox
1999-01-26T14:52:06Z

> > 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, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/