lkml.org 
[lkml]   [1999]   [Jan]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: MM deadlock [was: Re: arca-vm-8...]
Date
> 
> On Tue, 26 Jan 1999, Alan Cox wrote:
>
> > Something like
> >
> > Chop memory into 4Mb sized chunks that hold the perfectly normal and
> > existing pages and buddy memory allocator. Set a flag on 25-33% of them
> > to a max of say 10 and for <12Mb boxes simply say "tough".
>
> this is conceptually 'boot-time allocation of big buffers' by splitting
> all available memory into two pieces:
>
> size_kernel: generic memory
> size_user: only swappable
>
> (size_kernel+size_user = ca. size_allmemory)
>
> This still doesnt solve the 'what if we need more big buffers than
> size_user' and 'what if we need kernel memory more than size_kernel'
> questions, and both are valid.

Solved by reboot.

> 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?


-
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/

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