<p><br>
On May 31, 2012 9:37 PM, "Abu Rasheda" <<a href="mailto:rcpilot2010@gmail.com">rcpilot2010@gmail.com</a>> wrote:<br>
><br>
> On Wed, May 30, 2012 at 10:35 PM, Mulyadi Santosa<br>
> <<a href="mailto:mulyadi.santosa@gmail.com">mulyadi.santosa@gmail.com</a>> wrote:<br>
> > Hi...<br>
> ><br>
> > On Thu, May 31, 2012 at 4:44 AM, Abu Rasheda <<a href="mailto:rcpilot2010@gmail.com">rcpilot2010@gmail.com</a>> wrote:<br>
> >> as I increase size of buffer, insns per cycle keep decreasing. Here is the data:<br>
> >><br>
> >> 1k 0.90 insns per cycle<br>
> >> 8k 0.43 insns per cycle<br>
> >> 43k 0.18 insns per cycle<br>
> >> 100k 0.08 insns per cycle<br>
> >><br>
> >> Showing that copy_from_user is more efficient when copy data is small,<br>
> >> why it is so ?<br>
> ><br>
> > you meant, the bigger the buffer, the fewer the instructions, right?<br>
><br>
> yes<br>
><br>
If the buffer at user side is more then a page, then it may be that complete user space buffer is not available in memory and kernel spend time in processing page fault<br>
> ><br>
> > Not sure why, but I am sure it will reach some peak point.<br>
> ><br>
> > Anyway, you did kmalloc and then kfree()? I think that's why...bigger<br>
> > buffer will grab large chunk from slab...and again likely it's<br>
> > physically contigous. Also, it will be placed in the same cache line.<br>
> ><br>
> > Whereas the smaller one....will hit allocate/free cycle more...thus<br>
> > flushing the L1/L2 cache even more.<br>
><br>
> It seems to be doing opposite, bigger the allocation / copy longer stall is.<br>
><br>
> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
</p>