Re: Setting behavior for clustered IO

[Maksym Planeta]

Sergio Lopez <slp@sinrega.org> writes:

> El Mon, 02 Apr 2012 00:23:03 +0300
> Maksym Planeta <mcsim.planeta@gmail.com> escribió:
>
>> 
>> Hello,
>> 
>> I want to work upon implementing of clustered page reading in
>> GNU/Mach, as GSoC project.
>
> I'm happy to know that you will be working on this. After your success
> with the slab allocator, I'm pretty sure you're going to do a great
> job here.

Thank you :)

>
>> The goal of this project is not only add
>> ability of reading more than one page when page fault occurs, but
>> also implement appropriate interface for user to give him ability to
>> configure behavior at page faults. Usual way for this in
>> POSIX-compatible operating systems is using of function madvise.
>> 
>> This function allows user advise the kernel about how to handle paging
>> input/output in specified memory range. There are several behaviors,
>> like RANDOM, NORMAL, SEQUENTIAL, WILLNEED and DONTNEED. From the page
>> fault handler's point of view these behaviors differ only in size of
>> memory chunk that will be read ahead.
>
> I don't think the kernel should be the one to be advised, but the
> filesystem translators. These are the ones who really know current and
> future (as they control most of the operations) state of the object,
> and the number of pages which can be served after a page fault (cluster
> size).
>

If every filesystem translator had explicitly implement readahead
it would only complicate things. But if it was implemented, for
instance, in libpager as some routine and this routing could be
overloaded by translator, I think it would be interesting idea.

>> The project I suppose to work on is not new for GSoC. Two years ago a
>> student, whose nick on irc channel is kam, tried to implement
>> readahead, but didn't manage to do that for some reason. I looked
>> through patch he has sent and there he appended function
>> vm_behavior_set for setting behavior of page fault handler. As
>> parameter, this function  accepts constant, that specifies behavior
>> in way that is similar to the way is implemented in madvise.
>
> Instead of implementing a new call, I think
> memory_object_change_attributes should be extended to support setting
> the cluster size for a given object.

Indeed, this seems to be better.