lkml.org 
[lkml]   [2003]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Lse-tech] Re: Minutes from 10/1 LSE Call
Andrew Morton wrote:

>Hanna Linder <hannal@us.ibm.com> wrote:
>
>
>>In mainline, once block size is over 32k our throuput actually drops off.
>>It levels off around 128k but at a greater cpu utilization.
>>Dont really understand why that is.
>>
>>
>
>Probably thrashing the CPU's L1 cache.
>
>
>>In mm tree, maintains throughput for all block size but the cpu utilzation
>>keeps going up to do the same throughput. Readprofile shows the extra time
>>is being spent in copy_to_user (in mm tree). Backing out readahead patch
>>reduces cpu by 10% for all block sizes but still shows the spike. So that
>>isnt the main problem.
>>
>>
>
>If you have a loop like:
>
> char *buf;
>
> for (lots) {
> read(fd, buf, size);
> }
>
>
>the optimum value of `size' is small: as little as 8k. Once `size' gets
>close to half the size of the L1 cache you end up pushing the memory at
>`buf' out of CPU cache all the time.
>
>
>
Sure, but why do I only see this is the mm tree, and not the mainline
tree. Also, there are 160 threads doing this loop, so even at 32k block
size the working set of 'buf's is over 5MB with only a 2MB L2 cache.

Steve

>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Lse-tech mailing list
>Lse-tech@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/lse-tech
>
>

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.175 / U:0.404 seconds]
©2003-2014 Jasper Spaans. hosted at Digital Ocean