On Tuesday 07 March 2006 02:52, Benjamin LaHaise wrote:
Those 1-2 cycles are free if you look at how things get scheduled with the
execution of the surrounding code. I bet $20 that you can't find a modern
CPU where the cost is measurable (meaning something like a P4, Athlon).
If this
Benjamin LaHaise [EMAIL PROTECTED] wrote:
Hello Andrew et al,
The patch below adds a fast path that avoids the atomic dec and test
operation and spinlock acquire/release on page free. This is especially
important to the network stack which uses put_page() to free user
buffers.
Andrew Morton wrote:
Benjamin LaHaise [EMAIL PROTECTED] wrote:
Hello Andrew et al,
The patch below adds a fast path that avoids the atomic dec and test
operation and spinlock acquire/release on page free. This is especially
important to the network stack which uses put_page() to free user
On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
Am a bit surprised at those numbers.
Because userspace has to do peculiar things to get its pages taken off the
LRU. What exactly was that application doing?
It's just a simple send() and recv() pair of processes. Networking
Benjamin LaHaise [EMAIL PROTECTED] wrote:
On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
Am a bit surprised at those numbers.
Because userspace has to do peculiar things to get its pages taken off the
LRU. What exactly was that application doing?
It's just a simple
Benjamin LaHaise wrote:
Hello Andrew et al,
The patch below adds a fast path that avoids the atomic dec and test
operation and spinlock acquire/release on page free. This is especially
important to the network stack which uses put_page() to free user
buffers. Removing these atomic ops
Benjamin LaHaise wrote:
On Mon, Mar 06, 2006 at 04:50:39PM -0800, Andrew Morton wrote:
Am a bit surprised at those numbers.
Because userspace has to do peculiar things to get its pages taken off the
LRU. What exactly was that application doing?
It's just a simple send() and recv()
On Mon, Mar 06, 2006 at 05:39:41PM -0800, Andrew Morton wrote:
It's just a simple send() and recv() pair of processes. Networking uses
pages for the buffer on user transmits.
You mean non-zero-copy transmits? If they were zero-copy then those pages
would still be on the LRU.
Correct.
On Tue, Mar 07, 2006 at 12:53:27PM +1100, Nick Piggin wrote:
You can't do this because you can't test PageLRU like that.
Have a look in the lkml archives a few months back, where I proposed
a way to do this for __free_pages(). You can't do it for put_page.
Even if we know that we are the
Benjamin LaHaise wrote:
On Tue, Mar 07, 2006 at 12:53:27PM +1100, Nick Piggin wrote:
You can't do this because you can't test PageLRU like that.
Have a look in the lkml archives a few months back, where I proposed
a way to do this for __free_pages(). You can't do it for put_page.
Even if
On Tue, Mar 07, 2006 at 01:04:36PM +1100, Nick Piggin wrote:
I'd say it will turn out to be more trouble than its worth, for the
miserly cost
avoiding one atomic_inc, and one atomic_dec_and_test on page-local data
that will
be in L1 cache. I'd never turn my nose up at anyone just having a
Nick Piggin wrote on Monday, March 06, 2006 6:05 PM
My patches in -mm avoid the lru_lock and disabling/enabling interrupts
if the page is not on lru too, btw.
Can you put the spin lock/unlock inside TestClearPageLRU()? The
difference is subtle though.
- Ken
--- ./mm/swap.c.orig
Benjamin LaHaise wrote:
On Tue, Mar 07, 2006 at 01:04:36PM +1100, Nick Piggin wrote:
I'd say it will turn out to be more trouble than its worth, for the
miserly cost
avoiding one atomic_inc, and one atomic_dec_and_test on page-local data
that will
be in L1 cache. I'd never turn my nose up at
Chen, Kenneth W wrote:
Nick Piggin wrote on Monday, March 06, 2006 6:05 PM
My patches in -mm avoid the lru_lock and disabling/enabling interrupts
if the page is not on lru too, btw.
Can you put the spin lock/unlock inside TestClearPageLRU()? The
difference is subtle though.
That's the
14 matches
Mail list logo
