lkml.org 
[lkml]   [2000]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux Status For 2.3.x: v 2.3.43
On Thu, 17 Feb 2000, Stephen C. Tweedie wrote:

> Hi,
>
> On Thu, 17 Feb 2000 02:36:03 -0500 (EST), Alexander Viro
> <viro@math.psu.edu> said:
>
> > On Fri, 11 Feb 2000, Stephen C. Tweedie wrote:
>
> >> There are basically three things we need to deal with.
> >>
> >> * Freeing memory.
> >>
> >> The simple one. An application wants more memory, so we need to throw
> >> something out of cache.
>
> > Probable point where we call it being shrink_mmap(). Other candidates?
>
> shrink_mmap() is the obvious place. The biggest problem is that we will
> need to export enough functionality to allow other filesystems to
> hook their own data structures onto the page cache LRU list, so that
> filesystem-specific caches can be reclaimed in the same shrink_mmap()
> loop.

You are going to run into some actual scheduling conflicts. A relatively
low CPU/memory program can generate I/O which can flood an I/O channel. To
avoid the flood, that program will have to be suspended... and that might
result in a high idle time. The schedular must know not to run that
program and that the idle time is for the "best". That I/O flood will be a
problem only if there are contending programs which also need to do I/O on
that channel.

That suggests to me a more inclusive scheduler which handles resource
contention beyond just CPU and memory.

john alvord


-
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:56    [W:0.372 / U:0.020 seconds]
©2003-2011 Jasper Spaans. Advertise on this site