> From: Minchan Kim [mailto:minchan.kim@xxxxxxxxx] > On Sat, Apr 16, 2011 at 3:53 AM, Dan Magenheimer > <dan.magenheimer@xxxxxxxxxx> wrote: > >> From: OGAWA Hirofumi [mailto:hirofumi@xxxxxxxxxxxxxxxxxx] > >> > >> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes: > >> > > Andrew, I wonder if you would be so kind as to read the following > > and make a "ruling". ÂIf you determine a preferable set of names, > > I will abide by your decision and repost (if necessary). > > > > The problem is this: The English language has a limited number > > of words that can be used to represent data motion and mapping > > and most/all of them are already used in the kernel, often, > > to quote Andrew, "in confusing ways." ÂComplicating this, I > > think the semantics of the cleancache operations are different > > from the semantics of any other kernel operation... intentionally > > so, because the value of cleancache is a direct result of those > > differing semantics. ÂAnd the cleancache semantics > > are fairly complex (again intentionally) so a single function > > name can't possibly describe the semantics. > > > > The cleancache operations are: > > - put (page) > > - get (page) > > - flush page > > - flush inode > > - init fs > > - flush fs > > > > I think these names are reasonable representations of the > > semantics of the operations performed... but I'm not a kernel > > expert so there is certainly room for disagreement. ÂThough I > > absolutely recognize the importance of a "name", I am primarily > > interested in merging the semantics of the operations and > > would happily accept any name that kernel developers could > > agree on. ÂHowever, I fear that there will be NO name that > > will satisfy all, so would prefer to keep the existing names. > > If some renaming is eventually agreed upon, this could be done > > post-merge. > > > > Here's a brief description of the semantics: > > : > > <semantics for other operations elided> > > : > > The cleancache operation currently known as "get" has the > > following semantics: ÂDerive the filesystem-determined handle > > from this struct page. ÂIf cleancache contains a page matching > > that handle, recreate the page of data from cleancache and > > place the results in the pageframe referred to by the > > struct page. ÂThen delete in cleancache any record of the > > handle and any data associated with it, so that a > > subsequent "get" will no longer find a match for the handle; > > any space used for the data can also be freed. > > : > > <semantics for other operations elided> > > : > > At least, I didn't confused your semantics except just flush. That's > why I suggested only flush but after seeing your explaining, there is > another thing I want to change. The get/put is common semantic of > reference counting in kernel but in POV your semantics, it makes sense > to me but get has a exclusive semantic so I want to represent it with > API name. Maybe cleancache_get_page_exclusive. > > The summary is that I don't want to change all API name. Just two > thing. > (I am not sure you and others agree on me. It's just suggestion). > > 1. cleancache_flush_page -> cleancache_[invalidate|remove]_page > 2. cleancache_get_page -> cleancache_get_page_exclusive > Hi Minchan -- Thanks for continuing to be interested in this and sorry for my delayed response. Actually, your comment about "get_page_exclusive" points out an incompleteness in my description of the semantics for cleancache_get_page. First, I forgot to list cleancache_init_shared_fs, which is the equivalent of cleancache_init_fs but used for clustered filesystems. (Support is included in the patch for ocfs2 but I haven't played with it in quite some time and my focus has been on the other filesystems, so it slipped my mind :-} The cleancache_get_page operation has a slightly different semantics depending on which of the init_fs calls was used. However, the location of the cleancache_get_page hook is the same regardless of the fs, so the name of the operation must represent both semantics. In the case of init_fs (non-shared), the behavior of cleancache_get_page is that the get is "destructive"; the page is removed from cleancache on a successful get. In the case of a init_shared_fs, however, the get is "non-destructive"; the page is NOT removed from cleancache. When cleancache contains pages from multiple kernels (e.g. Xen guests or different machines in a RAMster cluster), this semantic difference can make a big performance difference for a clustered filesystem. Since zcache only contains pages for a single kernel, the difference is moot. Because of this, I am hesitant to add "exclusive" to the end of the name of the operation. > BTW, Nice description. > Please include it in documentation if we can't reach the conclusion. > It will help others to understand semantic of cleancache. Thanks! Nearly all of the description already exists in various places in the patch but I agree that it would be good if I add a new section to the Documentation file with the exact semantics. Dan -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
