Re: how does generic_file_read work with page_cache?

Stephen C. Tweedie (sct@redhat.com)
Fri, 17 Sep 1999 22:00:46 +0100 (BST)


Hi,

On Wed, 22 Sep 1999 03:39:07 +0000, "Peter J. Braam" <braam@cs.cmu.edu>
said:

> I wondered if someone could explain what is happening in
> generic_file_read and the page cache.

On 2.2 or 2.3, btw?

> More generically, I'd like to understand how in a file system I can
> "get" a page and use it to copy date into/out of it. How do I then put
> the page away? [I'm working on some experiments for a cluster file
> system exploiting object based disks, see
> ftp://ftp.inter-mezzo.org/pub/obd for some sample code.]

In a lot of cases, the filesystem doesn't: the VFS generic_*_page
functions do it for you (especially on 2.3), and the filesystem's
interaction is limited to locating the disk blocks on disk.

> There seem to be several patterns, but I can't figure them out:
> - functions modifying a page tend to lock the page, and unlock them
> understandbly

Yes. A page marked Locked is reserved for IO.

> - functions reading the page do a page_get -- but there is no page_put,
> instead they call the un-understandable page_cache_release.

Just to access the page, all you really need is a reference count
against it. For read, you only need to lock the page if it doesn't
already exist (to prevent somebody else from reading it while you
populate the page's contents).

> Below in the snippet from generic_page read, the normal path does:

> get_page(page)
> if all is well copy the data from the page
> page_cache_release(page)

> But the latter is in fact __free_page(page) which is defined in
> page_alloc.c and is very appropriately labeled as "You really aren't
> expected to understand this".

It's just dropping the refcount on the page. The un-understandable bit
only kicks in when the last reference is deleted and we return the page
to the free list, and as long as the page is in the page cache we are
guaranteed still to have at least one reference (the page cache itself
counts as a reference).

--Stephen

-
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/