On Friday 22 February 2008 09:26, Peter Zijlstra wrote:
On Thu, 2008-02-21 at 19:00 +0100, Eric Dumazet wrote:
Some oprofile results obtained while using tbench on a 2x2 cpu machine
were very surprising.
For example, loopback_xmit() function was using high number of cpu
cycles to
in struct page. Needed for lockless pagecache.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Signed-off-by: David S. Miller [EMAIL PROTECTED]
Broke the Cassini driver.
While it is true that, within the cassini driver, you converted
the counter bumps and tests accurately
On Wednesday 14 November 2007 17:37, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
I'm doing some oprofile runs now to see if I can get any more info.
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert's patch reverted).
27516
On Wednesday 14 November 2007 09:27, Nick Piggin wrote:
2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev-feastures
setting.
Will try that now.
Doesn't help (with vanilla kernel -- Herbert's patch applied).
data_len histogram drops to 0 and goes to len (I guess that's
On Wednesday 14 November 2007 22:10, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 09:27:39 +1100
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert's patch reverted).
...
I can't see that these numbers
On Wednesday 14 November 2007 22:48, Herbert Xu wrote:
On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote:
So the thing that's being effected here in TCP is
net/ipv4/tcp.c:select_size(), specifically the else branch:
Thanks for the pointer. Indeed there is a bug in that area.
On Thursday 15 November 2007 10:46, David Miller wrote:
From: Herbert Xu [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 19:48:44 +0800
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Applied and I'll queue it up for -stable too.
Good result. Thanks, everyone!
-
To unsubscribe from this list: send
On Thursday 15 November 2007 12:11, Herbert Xu wrote:
On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote:
Well this is likely the result of the SLUB regression. If you allocate an
order 1 page then the zone locks need to be taken. SLAB queues the a
Yeah, it appears this is
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
On Sat, 10 Nov 2007, Nick Piggin wrote:
BTW. your size-2048 kmalloc cache is order-1 in the default setup,
wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And
SLAB also uses order-0 for size-2048. It would
On Wednesday 14 November 2007 12:58, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 13 Nov 2007 22:41:58 +1100
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
On Sat, 10 Nov 2007, Nick Piggin wrote:
BTW. your size-2048 kmalloc cache is order-1
On Wednesday 14 November 2007 17:12, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 14 Nov 2007 04:36:24 +1100
On Wednesday 14 November 2007 12:58, David Miller wrote:
I suspect the issue is about having a huge skb-data linear area for
TCP sends over loopback. We're
On Saturday 10 November 2007 12:29, Nick Piggin wrote:
cc'ed linux-netdev
Err, make that 'netdev' :P
On Saturday 10 November 2007 10:46, Christoph Lameter wrote:
commit deea84b0ae3d26b41502ae0a39fe7fe134e703d0 seems to cause a drop
in SLUB tbench performance:
8p x86_64 system
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 14:51 +1100, Nick Piggin wrote:
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow PF_MEMALLOC to be set in softirq context. When running softirqs
from a borrowed context save current-flags
On Wednesday 31 October 2007 21:42, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 14:37 +1100, Nick Piggin wrote:
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
contexts that are entitled to it.
Care
On Wednesday 31 October 2007 23:17, Peter Zijlstra wrote:
On Wed, 2007-10-31 at 21:46 +1100, Nick Piggin wrote:
And I'd prevent these ones from doing so.
Without keeping track of reserve pages, which doesn't feel
too clean.
The problem with that is that once a slab was allocated
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Hi,
Another posting of the full swap over NFS series.
Hi,
Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?
Also, have you ensured that
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Restrict objects from reserve slabs (ALLOC_NO_WATERMARKS) to allocation
contexts that are entitled to it.
Care is taken to only touch the SLUB slow path.
This is done to ensure reserve pages don't leak out and get consumed.
I think
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow the mempool to use the memalloc reserves when all else fails and
the allocation context would otherwise allow it.
I don't see what this is for. The whole point of when I fixed this
to *not* use the memalloc reserves is because
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Provide a method to get the upper bound on the pages needed to allocate
a given number of objects from a given kmem_cache.
Fair enough, but just to make it a bit easier, can you provide a
little reason of why in this patch (or reference
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Change ALLOC_NO_WATERMARK page allocation such that the reserves are system
wide - which they are per setup_per_zone_pages_min(), when we scrape the
barrel, do it properly.
IIRC it's actually not too uncommon to have allocations coming
On Wednesday 31 October 2007 15:37, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Wed, 31 Oct 2007 14:26:32 +1100
Is it really worth all the added complexity of making swap
over NFS files work, given that you could use a network block
device instead?
Don't be misled
On Wednesday 31 October 2007 03:04, Peter Zijlstra wrote:
Allow PF_MEMALLOC to be set in softirq context. When running softirqs from
a borrowed context save current-flags, ksoftirqd will have its own
task_struct.
What's this for? Why would ksoftirqd pick up PF_MEMALLOC? (I guess
that some
Satyam Sharma wrote:
#define atomic_read_volatile(v) \
({ \
forget((v)-counter);\
((v)-counter); \
})
where:
*vomit* :)
Stefan Richter wrote:
Nick Piggin wrote:
I don't know why people would assume volatile of atomics. AFAIK, most
of the documentation is pretty clear that all the atomic stuff can be
reordered etc. except for those that modify and return a value.
Which documentation is there?
Documentation
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Herbert Xu wrote:
On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote:
BTW, the sort of missing barriers that triggered this thread
aren't that subtle. It'll result in a simple lock-up if the
loop condition holds upon entry. At which
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Sure, now
that I learned of these properties I can start to audit code and insert
barriers where I believe they are needed, but this simply means that
almost all occurrences of atomic_read will get barriers (unless there
already
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Also, why would you want to make these insane accessors for atomic_t
types? Just make sure everybody knows the basics of barriers, and they
can apply that knowledge to atomic_t and all other lockless memory
accesses as well
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
It is very obvious. msleep calls schedule() (ie. sleeps), which is
always a barrier.
Probably you didn't mean that, but no, schedule() is not barrier because
it sleeps. It's a barrier because it's
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
I think they would both be equally ugly,
You think both these are equivalent in terms of looks:
|
while (!atomic_read(v)) { | while (!atomic_read_xxx(v
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Because they should be thinking about them in terms of barriers, over
which the compiler / CPU is not to reorder accesses or cache memory
operations, rather than special volatile accesses.
This is obviously just a taste thing
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
On Fri, 17 Aug 2007, Nick Piggin wrote:
Satyam Sharma wrote:
It is very obvious. msleep calls schedule() (ie. sleeps), which is
always a barrier.
Probably you didn't mean that, but no, schedule
Segher Boessenkool wrote:
Part of the motivation here is to fix heisenbugs. If I knew where
they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would
Chris Snook wrote:
Herbert Xu wrote:
On Thu, Aug 16, 2007 at 03:48:54PM -0400, Chris Snook wrote:
Can you find an actual atomic_read code snippet there that is
broken without the volatile modifier?
A whole bunch of atomic_read uses will be broken without the volatile
modifier once we
Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 06:42:50PM +0800, Herbert Xu wrote:
In fact, volatile doesn't guarantee that the memory gets
read anyway. You might be reading some stale value out
of the cache. Granted this doesn't happen on x86 but
when you're coding for the kernel you
Paul Mackerras wrote:
Nick Piggin writes:
So i386 and x86-64 don't have volatiles there, and it saves them a
few K of kernel text. What you need to justify is why it is a good
I'm really surprised it's as much as a few K. I tried it on powerpc
and it only saved 40 bytes (10 instructions
Paul Mackerras wrote:
Nick Piggin writes:
Why are people making these undocumented and just plain false
assumptions about atomic_t?
Well, it has only been false since December 2006. Prior to that
atomics *were* volatile on all platforms.
Hmm, although I don't think it has ever been
Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
I prefer burying barriers into other primitives.
When they should naturally be there, eg. locking
Segher Boessenkool wrote:
Please check the definition of cache coherence.
Which of the twelve thousand such definitions? :-)
Every definition I have seen says that writes to a single memory
location have a serial order as seen by all CPUs, and that a read
will return the most recent write
Paul E. McKenney wrote:
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
Especially since several big architectures don't have volatile in their
atomic_get and _set, I think it would be a step backwards to add them in
as a just in case thin now (unless there is a better reason
Segher Boessenkool wrote:
Part of the motivation here is to fix heisenbugs. If I knew where they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would
Paul E. McKenney wrote:
On Mon, Aug 13, 2007 at 01:15:52PM +0800, Herbert Xu wrote:
Paul E. McKenney [EMAIL PROTECTED] wrote:
On Sat, Aug 11, 2007 at 08:54:46AM +0800, Herbert Xu wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing.
Chris Snook wrote:
David Howells wrote:
Chris Snook [EMAIL PROTECTED] wrote:
cpu_relax() contains a barrier, so it should do the right thing. For
non-smp
architectures, I'm concerned about interacting with interrupt
handlers. Some
drivers do use atomic_* operations.
I'm not sure that
David Howells wrote:
Nick Piggin [EMAIL PROTECTED] wrote:
Why do you call SetPageUptodate when the page is not up to date?
That leaks uninitialised data, AFAIKS.
It only seems that way. If afs_prepare_write() is called, but doesn't return
an error, then afs_commit_write() will be called
David Howells wrote:
+/*
+ * prepare a page for being written to
+ */
+static int afs_prepare_page(struct afs_vnode *vnode, struct page *page,
+ struct key *key, unsigned offset, unsigned to)
+{
+ unsigned eof, tail, start, stop, len;
+ loff_t i_size, pos;
On Tue, Mar 06, 2007 at 02:20:55PM -0800, David Miller wrote:
From: Robert Olsson [EMAIL PROTECTED]
Date: Tue, 6 Mar 2007 14:26:04 +0100
David Miller writes:
Actually, more accurately, the conflict exists in how this GC
logic is implemented. The core issue is that hash table
On Mon, Mar 05, 2007 at 08:26:32PM -0800, David Miller wrote:
This is essentially a port of Nick Piggin's dcache hash table
patches to the routing cache. It solves the locking issues
during table grow/shrink that I couldn't handle properly last
time I tried to code up a patch like this.
On Tue, Mar 06, 2007 at 01:17:06AM -0800, David Miller wrote:
From: Nick Piggin [EMAIL PROTECTED]
Date: Tue, 6 Mar 2007 10:11:12 +0100
@@ -1449,6 +1472,12 @@ static struct dst_entry *ipv4_negative_a
%u.%u.%u.%u/%02x dropped\n
On Tue, Mar 06, 2007 at 10:23:44AM +0100, Eric Dumazet wrote:
On Tuesday 06 March 2007 10:11, Nick Piggin wrote:
Cool! I have some fixes for the rcu barrier issues, with some C-style
comments and questions :)
I was going to send you a fix first for the rcu barriers, then a
second
Mark Groves wrote:
Hi,
I have been been seeing a problem when using sendfile repeatedly on an
SMP server, which I believe is related to the problem that was
discovered recently with marking dirty pages. The bug, as well as a test
script, is listed at
Evgeniy Polyakov wrote:
On Thu, Nov 30, 2006 at 08:35:04AM +0100, Ingo Molnar ([EMAIL PROTECTED]) wrote:
Doesn't the provided solution is just a in-kernel variant of the
SCHED_FIFO set from userspace? Why kernel should be able to mark some
users as having higher priority?
What if workload of
Paul Jackson wrote:
Daniel wrote:
Inventing a new name for an existing thing is very poor taste on grounds of
grepability alone.
I wouldn't say 'very poor taste' -- just something that should be
done infrequently, with good reason, and with reasonable concensus,
especially from the key
Tom Tucker wrote:
On Thu, 2006-06-08 at 01:17 -0700, Andrew Morton wrote:
On Wed, 07 Jun 2006 15:06:55 -0500
Steve Wise [EMAIL PROTECTED] wrote:
+void c2_free(struct c2_alloc *alloc, u32 obj)
+{
+ spin_lock(alloc-lock);
+ clear_bit(obj, alloc-table);
+
Ravikiran G Thirumalai wrote:
On Thu, Mar 09, 2006 at 07:14:26PM +1100, Nick Piggin wrote:
Ravikiran G Thirumalai wrote:
Here's a patch making x86_64 local_t to 64 bits like other 64 bit arches.
This keeps local_t unsigned long. (We can change it to signed value
along with other arches
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()
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
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
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
Eric Dumazet wrote:
Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
--- a/include/linux/netdevice.h 2006-02-07 11:55:42.0 +0100
+++ b/include/linux/netdevice.h 2006-02-09 09:23:15.0 +0100
@@ -649,6 +649,19
David S. Miller wrote:
From: Matt Mackall [EMAIL PROTECTED]
Date: Wed, 14 Dec 2005 21:02:50 -0800
There needs to be two rules:
iff global memory critical flag is set
- allocate from the global critical receive pool on receive
- return packet to global pool if not destined for a socket with
Andi Kleen wrote:
I would just set the ra pointer to a single global structure if the allocation
fails. Then you can avoid all the other checks. It will slow down
things and trash some state, but not fail and nobody should expect good
performance after out of memory anyways. The only check
Andi Kleen wrote:
You don't want to always have bad performance though, so you
could attempt to allocate if either the pointer is null _or_ it
points to the global structure?
Remember it's after a GFP_KERNEL OOM. If that fails most likely
you have deadlocked somewhere else already because
62 matches
Mail list logo
