On Mon, Apr 14, 2003 at 09:17:59PM -0700, William Lee Irwin III wrote:
>> It's a bit of an open question as to how much of a difference this one
>> makes now, but it says "FIXME". fault_in_pages_writeable() and
>> fault_in_pages_readable() have a limited "range" with respect to the
>> size of the region they can prefault; as they are now, they are only
>> meant to handle spanning a page boundary. This converts them to iterate
>> over the virtual address range specified and so touch each virtual page
>> within it once as specified. As per the comment within the "FIXME",
>> this is only an issue if PAGE_SIZE < PAGE_CACHE_SIZE.
>> [patch snip]
On Tue, Apr 15, 2003 at 07:52:29AM +0200, Antonio Vargas wrote:
> Page clustering? I did a simple patch yesterday called "cow-ahead", which
> may be related: on a write to a COW page, it breaks the COW from several pages
> at the same time. The implementation survived a complete debian 2.2 boot
> and a fork bomb. Please have a look. The idea came from a discussion with
> Martin J. Bligh... we liked the name too much not to implement it.
I apologize if the name is deceiving, but it's conventional. I saw your
patch and it could very well be valuable, but it would be called
"prefaulting" or "faultahead". Page clustering is divorcing the TLB
mapping unit from the kernel's internal allocation unit, specifically,
enlarging the kernel's allocation unit for reductions in the size of
certain data structures (for PAE, the most important of these is the
mem_map[] array but the pagecache radix trees also see good reductions),
and for physical contiguity benefits in things like io as they are
applicable (it is not applicable to workloads with many small files or
for workloads with predominantly small io sizes).
The article on kerneltrap.org on the subject should have more pointers
to explanatory posts etc. to get a better idea of what's going on.
Also important is to properly credit Hugh Dickins with the original
2.4 implementation of page clustering, which for optimality and
correctness and cleanliness is superior to the current state of my own
for 2.5, and is the source base from which my implementation is derived.
-- wli
-
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/
This archive was generated by hypermail 2b29 : Tue Apr 15 2003 - 22:00:35 EST