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/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:20 EST