Re: [RFC][patch 0/2] mm: remove PageReserved

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> We do what's most efficient for the core.  Which I think is refcount
> both ways regardless, since these "page"s are exceptional, and the
> majority really do need refcounting.

Well, refcounting _might_ be useful for some usage of these, but we
simply must make sure that those pages are never returned back to the
pool when refcount reach 0, that's it.

> But you don't mind if they are refcounted, do you?
> Just so long as they start out from 1 so never get freed.

Well, a refcounting bug would let them be freed and kaboom ... That's
why a "PG_not_your_ram_dammit" bit would be useful. It could at least
BUG_ON when refcount reaches 0 :)

> You'll actually be needing nopage() on them? 

Yes.

> That idea has come up
> before, it's not out of the question (though I think wli suggested
> we ought rather to change the nopage interface if so), but it's a
> different topic from the current removal of PageReserved anyway.

It is a different topic indeed. Wli proposal would be useful for us
here, but in the meantime, We can just create struct pages and rely on
sparsemem to have a not-too-horrible mem_map :)

Ben.


-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux