On Tue, Aug 14, 2007 at 07:21:03AM -0700, Christoph Lameter wrote:
> The following patchset implements recursive reclaim. Recursive reclaim
> is necessary if we run out of memory in the writeout patch from reclaim.
>
> This is f.e. important for stacked filesystems or anything that does
> complica
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
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
On Mon, Aug 13, 2007 at 08:00:38PM -0700, Andrew Morton wrote:
> On Mon, 13 Aug 2007 14:30:31 +0200 Jens Axboe <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Aug 06 2007, Nick Piggin wrote:
> > > > > What CPU did you get these numbers on? Do the indirect calls hurt
&
On Mon, Aug 13, 2007 at 10:05:01AM -0400, Lee Schermerhorn wrote:
> On Mon, 2007-08-13 at 09:43 +0200, Nick Piggin wrote:
> >
> > Replication may be putting more stress on some locks. It will cause more
> > tlb flushing that can not be batched well, which could cause the
On Sat, Aug 11, 2007 at 02:07:43AM +0200, Andi Kleen wrote:
>
> Nick,
>
> These two patches make my P4 (single socket HT) test box not boot. I dropped
> them for now.
>
> Some oopses
Sorry, the trylock had a race where it would not work correctly :(
Have fixed it now and will do more testing a
On Fri, Aug 10, 2007 at 05:08:18PM -0400, Lee Schermerhorn wrote:
> On Wed, 2007-08-08 at 16:25 -0400, Lee Schermerhorn wrote:
> > On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > > Hi,
> > >
> > > Just got a bit of time to take another look at the r
On Thu, Aug 09, 2007 at 04:37:35PM +0100, Hugh Dickins wrote:
> On Thu, 9 Aug 2007, Mariusz Kozlowski wrote:
> > Hello,
> >
> > Nothing unusual happening, allmodconfig compiling etc.
> > Not sure why it says kernel was tainted though ... hmmm.
> >
> > [ cut here ]
> >
On Wed, Aug 08, 2007 at 12:26:55PM +0200, Andi Kleen wrote:
>
> > *
> > * (the type definitions are in asm/spinlock_types.h)
> > */
> >
> > +#if (NR_CPUS > 256)
> > +#error spinlock supports a maximum of 256 CPUs
> > +#endif
> > +
> > static inline int __raw_spin_is_locked(raw_spinlock_t
On Wed, Aug 08, 2007 at 01:31:58PM -0400, [EMAIL PROTECTED] wrote:
> On Wed, 08 Aug 2007 06:24:44 +0200, Nick Piggin said:
>
> > After this, we can no longer spin on any locks with preempt enabled,
> > and cannot reenable interrupts when spinning on an irq safe lock, because
&g
tical sections short, and ensure locks are reasonably fair (which this
patch does).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-x86_64/spinlock.h
===
--- linux-2.6.orig/include/asm-x86_64/spinlock.
do they even get bloated up
with that break_lock then?).
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/s
On Mon, Aug 06, 2007 at 11:40:55AM -0700, Andrew Morton wrote:
> On Thu, 2 Aug 2007 07:24:46 +0200 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Rather than sign direct radix-tree pointers with a special bit, sign
> > the indirect one that hangs off the root.
--- [EMAIL PROTECTED] wrote:
> On Mon, 6 Aug 2007, Nick Piggin wrote:
>
> > [EMAIL PROTECTED] wrote:
> >> On Sun, 29 Jul 2007, Rene Herman wrote:
> >>
> >> > On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote:
> >> >
> >> > &g
On Sat, Aug 04, 2007 at 08:50:37AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Oh good. Thanks for getting to the bottom of it. We have normally
> > disliked too much runtime tunables in the scheduler, so I assume these
> >
.
It has not. Concerns that were raised (by specifically Nick Piggin)
weren't being addressed.
I may have missed them, but what I saw from him weren't specific issues,
but instead a nebulous 'something better may come along later'
Something better, ie. the problems wit
Matthew Hawkins wrote:
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
I guess /proc/meminfo, /proc/zoneinfo, /proc/vmstat, /proc/slabinfo
before and after the updatedb run with the latest kernel would be a
first step. top and vmstat output during the run wouldn't hurt either.
On Fri, Aug 03, 2007 at 01:10:13PM -0700, Suresh B wrote:
> On Fri, Aug 03, 2007 at 02:20:10AM +0200, Nick Piggin wrote:
> > On Thu, Aug 02, 2007 at 11:33:39AM -0700, Martin Bligh wrote:
> > > Nick Piggin wrote:
> > > >On Wed, Aug 01, 2007 at 03:52:11PM -0700, Marti
On Thu, Aug 02, 2007 at 06:34:04PM -0700, Christoph Lameter wrote:
> On Fri, 3 Aug 2007, Nick Piggin wrote:
>
> > Yeah it only gets set if the parent is initially using a default policy
> > at this stage (and then is restored afterwards of course).
>
> Uggh. Looks li
On Thu, Aug 02, 2007 at 06:02:56PM -0700, Christoph Lameter wrote:
> On Fri, 3 Aug 2007, Nick Piggin wrote:
>
> > > Ok. So MPOL_BIND on a single node. We would have to save the current
> > > memory policy on the stack and then restore it later. Then you would need
>
On Thu, Aug 02, 2007 at 05:52:28PM -0700, Christoph Lameter wrote:
> On Fri, 3 Aug 2007, Nick Piggin wrote:
>
> > > Add a (slow) kmalloc_policy? Strict Object round robin for interleave
> > > right? It probably needs its own RR counter otherwise it disturbs the
On Thu, Aug 02, 2007 at 12:58:13PM -0700, Christoph Lameter wrote:
> On Thu, 2 Aug 2007, Nick Piggin wrote:
>
> > > It does in the sense that slabs are allocated following policies. If you
> > > want to place individual objects then you need to use kmalloc_node().
>
On Thu, Aug 02, 2007 at 11:33:39AM -0700, Martin Bligh wrote:
> Nick Piggin wrote:
> >On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote:
> >>>And so forth. Initial forks will balance. If the children refuse to
> >>>die, forks will continue to bala
On Thu, Aug 02, 2007 at 05:44:47PM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > > > One thing to check out is whether the lmbench numbers are
> > > > > "correct". Especially on SMP systems, the lmbe
On Thu, Aug 02, 2007 at 09:19:56AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > One thing to check out is whether the lmbench numbers are "correct".
> > > Especially on SMP systems, the lmbench numbers are actually
not affect slot lookups which occur under lock -- they
can never return an invalid result. Is needed in future for lockless
pagecache.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/include/linux/radix-
On Tue, Jul 31, 2007 at 04:40:18PM -0700, Christoph Lameter wrote:
> On Tue, 31 Jul 2007, Andi Kleen wrote:
>
> > On Tuesday 31 July 2007 07:41, Nick Piggin wrote:
> >
> > > I haven't given this idea testing yet, but I just wanted to get some
> > > o
On Wed, Aug 01, 2007 at 07:31:26PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 2 Aug 2007, Nick Piggin wrote:
> >
> > lmbench 3 lat_ctx context switching time with 2 processes bound to a
> > single core increases by between 25%-35% on my Core2 system (didn'
Hi,
I didn't follow all of the scheduler debates and flamewars, so apologies
if this was already covered. Anyway.
lmbench 3 lat_ctx context switching time with 2 processes bound to a
single core increases by between 25%-35% on my Core2 system (didn't do
enough runs to get more significance, but i
On Wed, Aug 01, 2007 at 03:52:11PM -0700, Martin Bligh wrote:
>
> >And so forth. Initial forks will balance. If the children refuse to
> >die, forks will continue to balance. If the parent starts seeing short
> >lived children, fork()s will eventually start to stay local.
>
> Fork without ex
On Tue, Jul 31, 2007 at 05:55:13PM -0700, Suresh B wrote:
> On Wed, Aug 01, 2007 at 02:41:18AM +0200, Nick Piggin wrote:
> > On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote:
> > > task by taking away some of its cpu time. With CFS micro accounting,
> > > per
On Tue, Jul 31, 2007 at 10:14:03AM -0700, Suresh B wrote:
> On Tue, Jul 31, 2007 at 06:19:17AM +0200, Nick Piggin wrote:
> > On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote:
> > > So any suggestions for making this clean and acceptable to everyone?
> >
> >
On Tue, Jul 31, 2007 at 11:14:08AM +0200, Andi Kleen wrote:
> On Tuesday 31 July 2007 07:41, Nick Piggin wrote:
>
> > I haven't given this idea testing yet, but I just wanted to get some
> > opinions on it first. NUMA placement still isn't ideal (eg. tasks with
> &g
On Tue, Jul 31, 2007 at 10:01:14AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > This patch uses memory policies to attempt to improve this. It
> > requires that we ask the scheduler to suggest the child's new CPU
> >
Hi,
I haven't given this idea testing yet, but I just wanted to get some
opinions on it first. NUMA placement still isn't ideal (eg. tasks with
a memory policy will not do any placement, and process migrations of
course will leave the memory behind...), but it does give a bit more
chance for the m
On Mon, Jul 30, 2007 at 01:35:19PM -0700, Suresh B wrote:
> On Mon, Jul 30, 2007 at 11:20:04AM -0700, Christoph Lameter wrote:
> > On Fri, 27 Jul 2007, Siddha, Suresh B wrote:
>
> > > Observation #2: This introduces some migration overhead during IO
> > > submission.
> > > With the current protot
On Fri, Jul 27, 2007 at 10:30:47AM -0400, Lee Schermerhorn wrote:
> On Fri, 2007-07-27 at 10:42 +0200, Nick Piggin wrote:
> > Hi,
> >
> > Just got a bit of time to take another look at the replicated pagecache
> > patch. The nopage vs invalidate race and clear_page_dirt
lt 64BIT
Index: linux-2.6/mm/Makefile
===
--- linux-2.6.orig/mm/Makefile
+++ linux-2.6/mm/Makefile
@@ -29,4 +29,4 @@ obj-$(CONFIG_FS_XIP) += filemap_xip.o
obj-$(CONFIG_MIGRATION) += migrate.o
obj-$(CONFIG_SMP) += allocpercpu.o
On Thu, Jul 26, 2007 at 03:34:56PM -0700, Suresh B wrote:
> On Fri, Jul 27, 2007 at 12:18:30AM +0200, Ingo Molnar wrote:
> >
> > * Siddha, Suresh B <[EMAIL PROTECTED]> wrote:
> >
> > > Introduce SD_BALANCE_FORK for HT/MC/SMP domains.
> > >
> > > For HT/MC, as caches are shared, SD_BALANCE_FORK i
On Thu, Jul 26, 2007 at 09:05:15AM -0400, Chris Mason wrote:
> On Thu, 26 Jul 2007 04:36:39 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> [ are state trees a good idea? ]
>
> > > One thing it gains us is finding the start of the cluster. Even if
> >
Ray Lee wrote:
Another is a more philosophical hangup -- running a process that polls
periodically to improve system performance seems backward.
You mean like the kprefetchd of swap prefetch? ;)
Okay, so
that's my problem to get over, not yours.
If it was a problem you could add some even
Andrew Morton wrote:
On Thu, 26 Jul 2007 15:53:37 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Not that I want to say anything about swap prefetch getting merged: my
inbox is already full of enough "helpful suggestions" about that,
give them the kernel interfaces, they can
Andrew Morton wrote:
All this would end up needing runtime configurability and tweakability and
customisability. All standard fare for userspace stuff - much easier than
patching the kernel.
So. We can
a) provide a way for userspace to reload pagecache and
b) merge maps2 (once it's finishe
On Wed, Jul 25, 2007 at 10:10:07PM -0400, Chris Mason wrote:
> On Thu, 26 Jul 2007 03:37:28 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> >
> > > One advantage to the state tree is that it separates the state from
> > > the memory being described,
On Thu, Jul 26, 2007 at 11:44:22AM +1000, Dave Airlie wrote:
> >
> >Yeah I had a bit of a look around, and it seems OK (but would
> >appreciate an ack from someone who knows the code).
> >
> >These pages will never get seen by page reclaim, so we're OK
> >there. There is a get_page before the SetPa
On Wed, Jul 25, 2007 at 08:18:53AM -0400, Chris Mason wrote:
> On Wed, 25 Jul 2007 04:32:17 +0200
> Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > Having another tree to store block state I think is a good idea as I
> > said in the fsblock thread with Dave, but I haven&#x
[one more try]
On Thu, Jul 26, 2007 at 02:41:14AM +0200, Nick Piggin wrote:
> [forgot to cc Dave Jones...]
>
>
> On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote:
> > > Hi,
> > >
[forgot to cc Dave Jones...]
On Thu, Jul 26, 2007 at 07:26:53AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-07-25 at 13:19 +0200, Nick Piggin wrote:
> > Hi,
> >
> > Does this patch solve the X problem? Does anyone see anything wrong
> > with it or know wh
d00806b183152af6d24f46f0c33f14162ca1262a.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index d535c40..3db4f40 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -1170,7 +1170,6 @@ void *agp_generic_alloc_page(struc
Jos Poortvliet wrote:
Nick
has been talking about 'fixing the updatedb thing' for years now, no patch
yet.
Wrong Nick, I think.
First I heard about the updatedb problem was a few months ago with people
saying updatedb was causing their system to swap (that is, swap prefetching
helped after up
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
And yet despite my repeated pleas, none of those people has yet spent
a bit of time with me to help analyse what is happening.
btw., it might help to give specific, precise instructions about what
people should do to he
[EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Nick Piggin wrote:
And constructed test cases of course are useful as well, I didn't say
they weren't. I don't know what you mean by "acceptable", but you should
read my last paragraph again.
this problem has been ar
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 15:19 +1000, Nick Piggin wrote:
What *I* think is supposed to happen is that newly read in pages get
put on the inactive list, and unless they get accessed againbefore
being reclaimed, they are allowed to fall off the end of the list
without
Matthew Hawkins wrote:
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Not to say that neither fix some problems, but for such conceptually
big changes, it should take a little more effort than a constructed test
case and no consideration of the alternatives to get it merged.
Matthew Hawkins wrote:
On 7/25/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
I'm not saying that we can't try to tackle that problem, but first of
all you have a really nice narrow problem where updatedb seems to be
causing the kernel to completely do the wrong thing. So
[EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007, Nick Piggin wrote:
OK, this is where I start to worry. Swap prefetch AFAIKS doesn't fix
the updatedb problem very well, because if updatedb has caused swapout
then it has filled memory, and swap prefetch doesn't run unless there
is f
Dave Airlie wrote:
Is this with a binary-only module? We saw an issue with that in SLES9
where the module is returning a locked page from its nopage handler
when it isn't really supposed to. It might be fixed in latest drivers,
have you tried them?
Doesn't sound like it he mentions radeon drm
Eric St-Laurent wrote:
On Wed, 2007-25-07 at 06:55 +0200, Rene Herman wrote:
It certainly doesn't run for me ever. Always kind of a "that's not the
point" comment but I just keep wondering whenever I see anyone complain
about updatedb why the _hell_ they are running it in the first place. If
Eric St-Laurent wrote:
On Mon, 2007-23-07 at 19:00 +1000, Nick Piggin wrote:
I don't like this kind of conditional information going from something
like readahead into page reclaim. Unless it is for readahead _specific_
data such as "I got these all wrong, so you can reclaim them&qu
Rene Herman wrote:
On 07/25/2007 06:06 AM, Nick Piggin wrote:
Ray Lee wrote:
Anyway, my point is that I worry that tuning for an unusual and
infrequent workload (which updatedb certainly is), is the wrong way
to go.
Well it runs every day or so for every desktop Linux user, and it has
Linus Torvalds wrote:
On Tue, 24 Jul 2007, Benjamin Herrenschmidt wrote:
Besides, as Nick pointed out, it prevents some valid optimizations.
No it doesn't. Not the ones on the functions that just do an inline asm.
The only valid optimization it might break is for "constant_test_bit()",
w
Benjamin Herrenschmidt wrote:
On Tue, 2007-07-24 at 17:55 -0400, Trond Myklebust wrote:
If you want to use bitops as spinlocks you should rather be using
. That also does the right thing w.r.t.
pre-emption and sparse locking annotations.
Heh, I didn't know about those... A bit annoying that
Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Also a random day at the desktop, it is quite a broad scope and
pretty well impossible to analyse.
It is pretty broad, but that's also what swap prefetch is targetting.
As for hard to analyze, I'm not sure
Bret Towe wrote:
for a while in -git I've had an issue that on boot when gdm loads the
screen stays black
using ctrl-f1 doesn't return to a console and killing X doesn't help any
ssh'ing into the box does work top only shows 100% io-wait
dmesg shows nothing odd
the work around I have is at the m
On Tue, Jul 24, 2007 at 07:25:09PM -0400, Chris Mason wrote:
> On Tue, 24 Jul 2007 23:25:43 +0200
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> The tree is a critical part of the patch, but it is also the easiest to
> rip out and replace. Basically the code stores a range by inserting
> an obje
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Are you saying that it is OK for the store to var to
be reordered below the clear_bit? If not, what are you
saying?
I might be making a radical turn-around here, but all of a
sudden I think it's actually a good idea to
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
For the purpose of this discussion (Linux memory
barrier semantics, on WB memory), it is true of CPU
and compiler barriers.
On later Intel processors, if the memory address range being referenced
(and say written to) by the
--- Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On Tue, 24 Jul 2007, Nick Piggin wrote:
>
> > Satyam Sharma wrote:
> > > Consider this (the above two functions exist
> only for clear_bit(),
> > > the atomic variant, as you already know), the
> _only_ me
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
[...]
__test_and_change_bit is one that you could remove the memory clobber
from.
Yes, for the atomic versions we don't care if we're asking gcc to
generate trashy code (even though I'd have wanted to only disal
Jeremy Fitzhardinge wrote:
Satyam Sharma wrote:
Consider this (the above two functions exist only for clear_bit(),
the atomic variant, as you already know), the _only_ memory reference
we care about is that of the address of the passed bit-string:
(1) The compiler must not optimize / elid it (
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma <[EMAIL PROTECTED]>
[8/8] i386: bitops: smp_mb__{before, after}_clear_bit() definitions
From Documentation/atomic_ops.txt, those archs that require explicit
memory barriers
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Satyam Sharma wrote:
From: Satyam Sharma <[EMAIL PROTECTED]>
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
But test_
Satyam Sharma wrote:
On Tue, 24 Jul 2007, Nick Piggin wrote:
Linus Torvalds wrote:
Of course, if we remove all "volatiles" in data in the kernel (with the
possible exception of "jiffies"), we can then remove them from function
declarations too, but it should be done i
Ray Lee wrote:
On 7/23/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
That said, I'm willing to run my day to day life through both a swap
prefetch kernel and a normal one. *However*, before I go through all
the work of instrumenting the damn thing, I'd really like Andrew (or
L
Fengguang Wu wrote:
On Mon, Jul 23, 2007 at 12:40:09PM -0700, Andrew Morton wrote:
This is all fun stuff, but how do we find out that changes like this are
good ones, apart from shipping it and seeing who gets hurt 12 months later?
One thing I can imagine now is that the first pages may get
Linus Torvalds wrote:
On Mon, 23 Jul 2007, Satyam Sharma wrote:
[4/8] i386: bitops: Kill volatile-casting of memory addresses
This is wrong.
The "const volatile" is so that you can pass an arbitrary pointer. The
only kind of abritraty pointer is "const volatile".
In other words, the "v
Jesper Juhl wrote:
On 10/07/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
On Tuesday 10 July 2007 18:31, Andrew Morton wrote:
> When replying, please rewrite the subject suitably and try to Cc: the
> appropriate developer(s).
~swap prefetch
Nick's only remaining issue which I could remotely iden
Satyam Sharma wrote:
From: Satyam Sharma <[EMAIL PROTECTED]>
[6/8] i386: bitops: Don't mark memory as clobbered unnecessarily
The goal is to let gcc generate good, beautiful, optimized code.
But test_and_set_bit, test_and_clear_bit, __test_and_change_bit,
and test_and_change_bit unnecessarily
PROTECTED]>
Cc: David Howells <[EMAIL PROTECTED]>
Cc: Nick Piggin <[EMAIL PROTECTED]>
---
[ A similar optimization needs to be done in the atomic.h also.
Will submit that patch shortly. ]
include/asm-i386/bitops.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(
Rusty Russell wrote:
On Sun, 2007-07-22 at 16:10 +0800, Fengguang Wu wrote:
So I opt for it being made tunable, safe, and turned off by default.
I hate tunables :) Unless we have workload A that gets a reasonable
benefit from something and workload B that gets a significant regression,
and n
want. Is radix_tree_scan_hole the best name?
What about radix_tree_next_hole or _find_next_hole? (Andrew, any
suggestions?)
Cc: Nick Piggin <[EMAIL PROTECTED]>
Signed-off-by: Fengguang Wu <[EMAIL PROTECTED]>
---
include/linux/radix-tree.h |2 ++
lib/radix-tree.c
Linus Torvalds wrote:
On Fri, 20 Jul 2007, Nick Piggin wrote:
So you did. Then to answer that, yes it could be faster because there are
stupid volatiles sprinkled all over the bitops code so you could easily
end up having to do more loads. Does it make a real difference? Unlikely,
but David
Dave Airlie wrote:
On 7/19/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Thu, 19 Jul 2007 18:15:03 +1000 "Dave Airlie" <[EMAIL PROTECTED]>
wrote:
> Maybe we could add CONFIG_HAVE_CMPXCHG and let DRM depend on it..
That would certainly be better than adding a sprinkle of architectures
in DR
(sorry if this is a resend... something bad seems to have happened to me)
Andrew Morton wrote:
On Thu, 19 Jul 2007 08:51:49 -0700 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
This code doesn't have all the ghastly tricks which we deploy to handle
concurrent truncate.
Do I need to ? Baaahh!!
Andrew Morton wrote:
On Thu, 19 Jul 2007 08:51:49 -0700 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
This code doesn't have all the ghastly tricks which we deploy to handle
concurrent truncate.
Do I need to ? Baaahh!! I don't want to deal with them.
Nick, can you think of any serious con
Andrew Morton wrote:
On Wed, 18 Jul 2007 15:56:53 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
+ if (type == AFS_LOCK_READ &&
+ vnode->flags &
Nishanth Aravamudan wrote:
On 19.07.2007 [09:58:50 -0700], Andrew Morton wrote:
On Thu, 19 Jul 2007 08:51:49 -0700 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
+ }
+
+ offset += ret;
+ retval += ret;
+ len -= ret;
+ index +
Andrew Morton wrote:
On Thu, 19 Jul 2007 08:51:49 -0700 Badari Pulavarty <[EMAIL PROTECTED]> wrote:
+ }
+
+ offset += ret;
+ retval += ret;
+ len -= ret;
+ index += offset >> HPAGE_SHIFT;
+ offset &= ~HPAGE_MAS
On Fri, Jul 20, 2007 at 09:56:03AM +0200, Joachim Deguara wrote:
> On Friday 20 July 2007 09:25:22 Nick Piggin wrote:
> > On Wed, Jul 18, 2007 at 11:11:30AM +0200, Joachim Deguara wrote:
> > > While learning about schedstats I found that the documentation in the
> > >
tions
> from.
Ah, thanks, I actually didn't realise there was such good documentation
there. Patch looks good.
BTW. I have a simple program to do a basic statistical summary of the
multiprocessor balancing if you are interested and haven't seen it.
Acked-by: Nick Piggin <[EMAIL
Fix page index to offset conversion overflows in buffer layer, ecryptfs,
and ocfs2.
It would be nice to convert the whole tree to page_offset, but for now
just fix the bugs.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
diff --git a/fs/buffer.c b/fs/buffer.c
index 02ebb1f..0e5ec37
Mathieu Desnoyers wrote:
I tried it with and without the LOCK prefix on my Pentium 4.
Locked cmpxchg8b : 90 cycles
Non locked cmpxchg8b: 30 cycles
sti: 166 cycles
cli: 159 cycles
So, hrm, even if we use the locked version, it is still much faster than
the sti/cli. I am thoughtful about the com
Andrew Morton wrote:
On Tue, 17 Jul 2007 13:47:32 +0100
David Howells <[EMAIL PROTECTED]> wrote:
+ if (type == AFS_LOCK_READ &&
+ vnode->flags & (1 << AFS_VNODE_READLOCKED)) {
Here we use
vnode->flags & (1 << foo)
+ set_bit(AFS_VNODE_LOCKING, &vnode
Nish Aravamudan wrote:
Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with, because of rounding and such. And it's simply exacerbated wi
On Tue, Jul 17, 2007 at 04:25:42PM +0200, Andi Kleen wrote:
>
>
> When you revamp everything I guess it would make the locks
> easier to read to just put them into a .S file? They're
> out of line anyways.
It is a bit tricky because of the way kernel/spinlock.c uses
the the inline asm (that, and
On Mon, Jul 16, 2007 at 11:49:40AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Jul 16, 2007 at 11:26:46AM +0200, Ingo Molnar wrote:
> > >
> > > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > >
> &
On Mon, Jul 16, 2007 at 11:26:46AM +0200, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > [...] trylock is more significantly slower, but they are relatively
> > rare.
>
> trylock is the main thing that the spinlock debugging code uses, an
On Mon, Jul 16, 2007 at 10:16:54AM +0100, Alan Cox wrote:
> > however the difference is quite small on Core2 and Opteron when working out
> > of
> > cache, and becomes almost insignificant even on P4 when the lock misses
> > cache.
> > trylock is more significantly slower, but they are relatively
Pekka Enberg wrote:
On 7/16/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Actually SLOB potentially has some fundamental CPU cache hotness
advantages over the other allocators, for the same reasons as
its space advantages.
Because consecutive allocations hit the same cache-hot page rega
Rafael J. Wysocki wrote:
The only direct relationship between the freezer and drivers is that some of
them use kernel threads that call try_to_freeze() (and other freezer-related
functions).
If removing thoset was the only benefit of getting rid of the freezer
with kexec, it would almost be wo
601 - 700 of 1974 matches
Mail list logo
