Re: fs block size and PAGE_CACHE_SIZE

Phillip Lougher
2003-05-12T11:18:31Z

David Chow wrote:

> Trond Myklebust wrote:
>
>>>>>>> " " == David Chow <davidchow@shaolinmicro.com> writes:
>>>>>>>
>>>>>>
>>
>> > How can you make sure there are no race conditions in
>> > populating multiple page caches and making them up-to-date
>> > afterwards? Since readpage only make sures you lock one page,
>>
>> Have a browse through mm/readahead.c (in particular read_pages() and
>> read_cache_pages()).
>> The page is is anonymous when it gets locked, and is only added to the
>> page cache) if there is no existing page. The lock is only released by
>> the filler.
>>
>> > If readpages() is added for 2.5, it doesn't mean read page
>> > don't have to implement readpage(), right?
>>
>> Right. You still have to implement readpage.
>>
> So it is impossible to do under 2.4? Since all the design of VFS and
> page cache assumes the underlying fs uses a 4k page or something
> equivalent less to the size of a PAGE_CACHE_SIZE as the largest unit
> of a cache. If you read Phillip Lougher's mail which points to the
> squash fs (read-only), plus the problem of sleeping which really
> impossible to implement a read/write fs on smp systems (which I
> suppose to, and the current fs already supported). If it is
> impossible, I don't bother to think though.

Hi,

I think you slightly mis-understood my post. There is no problem doing
this with SMP or pre-emptive kernels.

What I did say was to point out it was better to use grab_page_nowait()
rather than read_cache_page. The problem with read_cache_page is not to
with smp or pre-emptive kernels, it is to do with the fact
read_cache_page tries to grab the lock of the page it is called to fill.
If the page is already locked by another process, it will sleep on the
lock. Grab_page_nowait() doesn't wait if the page is locked.

Regards

Phillip Lougher

>
> regards,
> David Chow
>
>>
>>
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>