Date:	Fri,  7 Nov 2008 13:37:14 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	kosaki.motohiro@...fujitsu.com,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	linux-mm <linux-mm@...ck.org>
Subject: Re: [RFC][PATCH] mm: the page of MIGRATE_RESERVE don't insert into pcp

Hi Mel, Cristoph,

Thank you for interesting comment!


> > MIGRATE_RESERVE mean that the page is for emergency.
> > So it shouldn't be cached in pcp.
> 
> It doesn't necessarily mean it's for emergencys. MIGRATE_RESERVE is one
> or more pageblocks at the beginning of the zone. While it's possible
> that the minimum page reserve for GFP_ATOMIC is located here, it's not
> mandatory.
> 
> What MIGRATE_RESERVE can help is high-order atomic allocations used by
> some network drivers (a wireless one is what led to MIGRATE_RESERVE). As
> they are high-order allocations, they would be returned to the buddy
> allocator anyway.

yup.
my patch is meaningless for high order allocation because high order allocation
don't use pcp.


> What your patch may help is the situation where the system is under intense
> memory pressure, is dipping routinely into the lowmem reserves and mixing
> with high-order atomic allocations. This seems a bit extreme.

not so extreame.

The linux page reclaim can't process in interrupt context.
Sl network subsystem and driver often use MIGRATE_RESERVE memory although
system have many reclaimable memory.

At that time, any task in process context can use high order allocation.


> > otherwise, the system have unnecessary memory starvation risk
> > because other cpu can't use this emergency pages.
> > 
> > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
> > CC: Mel Gorman <mel@....ul.ie>
> > CC: Christoph Lameter <cl@...ux-foundation.org>
> > 
> 
> This patch seems functionally sound but as Christoph points out, this
> adds another branch to the fast path. Now, I ran some tests and those that
> completed didn't show any problems but adding branches in the fast path can
> eventually lead to hard-to-detect performance problems.
> 
> Do you have a situation in mind that this patch fixes up?

Ah, sorry for my description is too poor.
This isn't real workload issue, it is jsut 

Actually, I plan to rework to pcp because following pcp list searching 
in fast path is NOT fast.

In general, list searching often cause L1 cache miss, therefore it shouldn't be
used in fast path.


static struct page *buffered_rmqueue(struct zone *preferred_zone,
                        struct zone *zone, int order, gfp_t gfp_flags)
{
(snip)
                /* Find a page of the appropriate migrate type */
                if (cold) {
                        list_for_each_entry_reverse(page, &pcp->list, lru)
                                if (page_private(page) == migratetype)
                                        break;
                } else {
                        list_for_each_entry(page, &pcp->list, lru)
                                if (page_private(page) == migratetype)
                                        break;
                }


Therefore, I'd like to make per migratetype pcp list.
However, MIGRATETYPE_RESEVE list isn't useful because caller never need reserve type.
it is only internal attribute.

So I thought "dropping reserve type page in pcp" patch is useful although it is sololy used.
Then, I posted it sololy for hear other developer opinion.

Actually, current pcp is NOT fast, therefore the discussion of the 
number of branches isn't meaningful.
the discussion of the number of branches is only meaningful when the fast path can
process at N*branches level time, but current pcp is more slow.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists