Re: [PATCH 08/33] readahead: common macros

[Wu Fengguang <wfg@mail.ustc.edu.cn>]

On Thu, May 25, 2006 at 03:56:24PM +1000, Nick Piggin wrote:
> >+#include <linux/writeback.h>
> >+#include <linux/nfsd/const.h>
> >
> 
> How come you're adding these includes?

For something added in the past and removed later...

> >+#define PAGES_BYTE(size) (((size) + PAGE_CACHE_SIZE - 1) >> 
> >PAGE_CACHE_SHIFT)
> >+#define PAGES_KB(size)	 PAGES_BYTE((size)*1024)
> >
> Don't really like the names. Don't think they do anything for clarity, but
> if you can come up with something better for PAGES_BYTE I might change my
> mind ;) (just forget about PAGES_KB - people know what *1024 means)

No, they are mainly for concision. Don't you think it's cleaner to write
        PAGES_KB(VM_MAX_READAHEAD)
than
        (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE

Admittedly the names are somewhat awkward though :)

> Also: the replacements are wrong: if you've defined VM_MAX_READAHEAD to be
> 4095 bytes, you don't want the _actual_ readahead to be 4096 bytes, do you?
> It is saying nothing about minimum, so presumably 0 is the correct choice.

The macros were first introduced exact for this reason ;)

It is rumored that there will be 64K page support, and this macro
helps round up the 16K sized VM_MIN_READAHEAD. The eof_index also
needs rounding up.

> >+#define next_page(pg) (list_entry((pg)->lru.prev, struct page, lru))
> >+#define prev_page(pg) (list_entry((pg)->lru.next, struct page, lru))
> >
> 
> Again, it is probably easier just to use the expanded version. Then the
> reader can immediately say: ah, the next page on the LRU list (rather
> than, maybe, the next page in the pagecache).

Ok, will expand it.

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