[lkml]   [1996]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Bugs and wishes in memory management area

> DMA memory". That makes modules unreliable. Of course I don't see
> why modules are apparently using GFP_ATOMIC | GFP_DMA. When loading a
> module I think we can swap.

GFP_DMA implies GFP_ATOMIC (rightly or wrongly)

> Wishes for memory management in 2.1
> First: Real swapping. When two processes are fighting for memory and
> memory is tight only way to make progress is freezing one of them and
> let the other run unimpeded for a few seconds.

Questionable. The shared set of pages in most systems is a lot of the
application. Also the 'less regularly used' algorithm behaves far more
stably with heavy loads. I can see a case for trying to pick more on
processes that have run a lot but the whole VM/scheduling/IO interaction
is an incredibly complex and subtle beast. Repeating the formulae of the
early 1980's isnt always progress

> Second: Linux does not write to swap, pages who have never been
> modified like code pages. This way Linux does not lose time wring
> them. But because reading from swap is faster I think when a page is
> being recalled for thez upteemth time it would be wise to write it to
> swap. We will get it faster next times. However it seems it would

I would like to make this a mount configurable option - specifically in
my case for NFS and CDROM file systems where local swap is far cheaper
to access. Sure if its coded right it will work on disks if you want.
However nobody has volunteered to write it yet

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