Re: Possible Idea with filesystem buffering.

Rolf Lear (rolf-linux@bits.dyndns.org)
22 Jan 2002 21:02:52 -0000


Excuse me for being a kernel newbie (and a list lurker), and for simplifying what is obviously a complex issue... but ... the underlying issue really is simple. Further, you are both suggesting that a change in design is not out-of-the-question.

The VM is responsible for making sure that Mem is used efficiently. The FS is responsible for making sure that the disks (both space and speed) are used efficiently.

Now, I have followed this thread for days, and I agree with Rik that the VM should be able to tell (command) the FS to free a page. I agree with Hans that "Ideally", the VM should be capable of identifying the best page to free (in terms of cost to the FS). In this ideal world, it is the responsibility of an intelligent FS to inform an intelligent VM what it can do quickly, and what will take time.

What I propose is either:
a) An indication on each dirty page the cost required to clean it.
b) A FS function which can be called which indicates the cost of a clean.

This cost should be measured in terms of something relevant like approximate IO time. FS's which do not support this system should have stubs which cost all pages equally.

The system would work as follows:
VM Needs to free some Mem, and not enough clean pages can be freed.
VM Identifies those dirty pages which are cheap to flush/clean, and does it. If VM Needs to flush an expensive page, it can still do it, but it knows whe price ahead of time (double bonus).

To identify the cheap pages, the VM can ask the FS the price, and as an added bonus, the FS can tell the VM how many other pages will get freed in the process.

In my world of client-server / databases / etc, this just makes sense.

If this intelligent VM has a basic FS, it looses nothing. If it has an intelligent FS, it has more information to make better decisions.

Rolf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/