[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071114111742.GB9566@skynet.ie>
Date: Wed, 14 Nov 2007 11:17:42 +0000
From: mel@...net.ie (Mel Gorman)
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: akpm@...l.org, torvalds@...l.org, linux-kernel@...r.kernel.org,
linux-mm@...r.kernel.org, apw@...dowen.org
Subject: Re: Major mke2fs slowdown (reproducable, bisected)
On (13/11/07 16:54), Mel Gorman didst pronounce:
> fixes your problem.... As I write this, it occurs to me that it might be
> because your compile-job has created very long free-lists and searching them
> is causing problems.
This indeed did appear to be the problem. When a basic compile-job was
run first, the mke2fs times on a vanilla kernel were
119.96 real, 0.08 user, 19.85 sys
194.91 real, 0.11 user, 24.71 sys
102.24 real, 0.08 user, 10.47 sys
104.66 real, 0.08 user, 10.45 sys
100.77 real, 0.13 user, 10.54 sys
and with the patch reverted was
121.83 real, 0.15 user, 11.16 sys
126.68 real, 0.10 user, 10.78 sys
104.47 real, 0.09 user, 10.48 sys
104.75 real, 0.10 user, 10.66 sys
106.06 real, 0.09 user, 10.55 sys
The high sys times initially are due to the number of fallbacks that
take place as creating a filesystem creates an unusually large number of
pinned pages for a short-period of time. The search times usually
unmeasurably then show up in the profiles.
Reverting the patch is still the right solution. We will find an alternative
way of biasing the placement of pages without the expensive search.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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