![]() | |||||||||||||
Messages in this thread |
On Wednesday 25 June 2003 03:10, William Lee Irwin III wrote: > On Wednesday 25 June 2003 02:47, William Lee Irwin III wrote: > >> Per struct address_space? This is an unnecessary limitation. > > On Wed, Jun 25, 2003 at 03:07:18AM +0200, Daniel Phillips wrote: > > It's a sensible limitation, it keeps the radix tree lookup simple. > > It severely limits its usefulness. Dropping in a more flexible data > structure should be fine. Eventually it could well make sense to do that, e.g., the radix tree eventually ought to evolve into a btree of extents (probably). But making things so complex in the first version, thus losing much of the incremental development advantage, would not be smart. With a single size of page per address_space, changes to the radix tree code are limited to a couple of lines, for example. But perhaps you'd like to supply some examples where more than one size of page in the same address space really matters? > On Wednesday 25 June 2003 02:47, William Lee Irwin III wrote: > >> This gives me the same data structure proliferation chills as bh's. > > On Wed, Jun 25, 2003 at 03:07:18AM +0200, Daniel Phillips wrote: > > It's not nearly as bad. There is no distinction between subpage and base > > struct page for almost all page operations, e.g., locking, IO, data > > access. > > But those are code sanitation issues. You need to make sure this > doesn't explode on PAE. Indeed, that is important. Good night, see you tomorrow. Daniel - 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/ | ||||||||||||
| Last update: 2005-03-22 12:36 [from the cache] ©2003-2008 | |||||||||||||