Matt Mackall wrote:
On Tue, Jun 26, 2007 at 02:06:15PM +1000, Nick Piggin wrote:
Yoshinori Sato wrote:
At Fri, 22 Jun 2007 09:56:35 -0500,
Matt Mackall wrote:
On Fri, Jun 22, 2007 at 05:08:07PM +0900, Yoshinori Sato wrote:
Because the page which SLOB allocator got does not have PG_slab,
This is for a NOMMU system?
Yes.
You're using an old kernel with an old version of SLOB. SLOB in newer
kernels actually sets per-page flags. Nick, can you see any reason not
to s/PG_active/PG_slab/ in the current code?
The problem with this is that PG_private is used only for the SLOB
part of the allocator and not the bigblock part.
That's fine, at least for the purposes of kobjsize. We only mark
actual SLOB-managed pages, kobjsize assumes the rest are alloc_pages
and that's indeed what they are.
OK, but that only makes it work in this case. I think we should
either call PG_slab part of the kmem/kmalloc API and implement
that, or say it isn't and make nommu do something else?
We _could_ just bite the bullet and have SLOB set PG_slab, however
that would encouarage more users of this flag which we should hope
to get rid of one day.
The real problem is that nommu wants to get the size of either
kmalloc or alloc_pages objects and it needs to differentiate
between them. So I would rather nommu to take its own page flag
(could overload PG_swapcache, perhaps?), and set that flag on
pages it allocates directly, then uses that to determine whether
to call ksize or not.
I think we already established on the last go-round that the kobjsize
scheme was rather hopelessly broken anyway.
I can't remember, but that would be another good reason to confine
it to nommu.c wouldn't it?
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
