lkml.org 
[lkml]   [2008]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/4] Reclaim page capture v4
On Thu, Oct 02, 2008 at 11:46:12AM +0900, MinChan Kim wrote:
> Hi, Andy.
>
> I tested your patch in my desktop.
> The test is just kernel compile with single thread.
> My system environment is as follows.
>
> model name : Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
> MemTotal: 2065856 kB
>
> When I tested vanilla, compile time is as follows.
>
> 2433.53user 187.96system 42:05.99elapsed 103%CPU (0avgtext+0avgdata
> 0maxresident)k
> 588752inputs+4503408outputs (127major+55456246minor)pagefaults 0swaps
>
> When I tested your patch, as follows.
>
> 2489.63user 202.41system 44:47.71elapsed 100%CPU (0avgtext+0avgdata
> 0maxresident)k
> 538608inputs+4503928outputs (130major+55531561minor)pagefaults 0swaps
>
> Regresstion almost is above 2 minutes.
> Do you think It is a trivial?
>
> I know your patch is good to allocate hugepage.
> But, I think many users don't need it, including embedded system and
> desktop users yet.
>
> So I suggest you made it enable optionally.

Hmmm. I would not expect to see any significant impact for this kind of
workload as we should not be triggering capture for the lower order
allocations at all. Something screwey must be occuring. I will go and
reproduce this here and see if I can figure out just what causes this.

-apw


\
 
 \ /
  Last update: 2008-10-02 17:07    [W:0.157 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site