Messages in this thread | | | Date | Tue, 6 Apr 2004 23:54:41 +0200 | From | Andrea Arcangeli <> | Subject | Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix |
| |
On Mon, Apr 05, 2004 at 09:43:30PM -0700, Andrew Morton wrote: > It does pagebuf I/O with kmalloced memory? Wow. Pretty much anything > which goes from kmalloc virtual addresses back to pageframes is a big fat > warning sign.
it's tricky indeed, though it worked fine as far as compound was left disabled with hugetlbfs=n.
> Do you see any reason why we shouldn't flip things around and make the > hugetlb code explicitly request the compound page metadata when allocating > the pages?
I definitely agree we should reverse the logic to __GFP_COMP instead of __GFP_NO_COMP in mainline. Problem is I coudln't do it in the short term to avoid invalidating the testing done with hugetlbfs=y. Soon I can reverse it and add the __GFP_COMP only for the hugetlbfs big-order dyanmic allocations that should be quick to identify.
Christoph, I got no positive feedback yet for the alternate fix you proposed and it's not obvious to my eyes (isn't good_pages going to be screwed with your fix?), but I wanted to checkin a fix into CVS in the meanwhile, so for now I've checked in my __GFP_NO_COMP fix that I'm sure doesn't require any testing since it's obviously safe and it should definitely fix the problem. This way you can also take your time for the testing of your better fix.
What's not clear to me about your fix is if it's really working safe with good_pages being overdecremented (good_pages doesn't look just an hint, there seems to be a valid reason you're doing the set_bit/test_bit on page->private, no?).
thanks. - 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/
| |