Messages in this thread | | | Date | Thu, 02 Oct 2003 14:21:13 -0500 | From | Steven Pratt <> | Subject | Re: [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/
| |