Messages in this thread | | | Date | Wed, 14 Nov 2007 11:17:42 +0000 | Subject | Re: Major mke2fs slowdown (reproducable, bisected) | From | (Mel Gorman) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |