On Tuesday 30 October 2007 18:54, Lorenzo Allegrucci wrote:
> Hi, sorry if this is a faq but reading
> http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf (slides 17,
> 18)
> looks like 2.6.23 is having a performance regression on MySQL and
> PostgreSQL benchmarks. Has anyone investigated th
ill also avoid changing applicatoin behaviour due to a gdb read...
Thanks,
Nick
--
Duane Griffin noticed a 2.6.23 regression that will cause gdb to hang when
it tries to access the memory of another process beyond i_size.
This is because the solution to the fault vs invalidate race requires that
w
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 page_file
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 th
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 pro
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 referen
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 com
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
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
&g
k won't start running in the middle of
show_stack(). If there are any correctness issues, then the archietcture
would have to take further steps to ensure the task is not running.
Signed-off-by: Nick Piggin <[EMAIL PROTECTE
On Tue, Oct 30, 2007 at 11:56:00PM -0700, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 31 Oct 2007 07:42:21 +0100
>
> > Sysrq+T fails to show the stack trace of a running task. Presumably this
> > is to avoid a garbled stack, however it can o
On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
> Reported-by: Nick Piggin <[EMAIL PROTECTED]>
>
> The delay incurred in lock_page() should also be accounted in swap delay
> accounting
>
> Signed-off-by: Balbir Singh <[EMAIL PROTECTED]>
Ah right, I forgot to
On Wednesday 31 October 2007 18:41, Nick Piggin wrote:
> On Wednesday 31 October 2007 18:52, Balbir Singh wrote:
> > Reported-by: Nick Piggin <[EMAIL PROTECTED]>
> >
> > The delay incurred in lock_page() should also be accounted in swap delay
> > accounting
&g
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 bo
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
> > > conte
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.
&g
On Wed, Oct 31, 2007 at 08:11:10AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > However I actually don't really like how this all works. I don't like that
> > filemap.c should have to know about ptrace, or exactly
On Wed, Oct 31, 2007 at 08:59:41AM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > Well the patch is right, in the context of the regression I introduced
> > (and so it should probably go into 2.6.23).
>
> Yeah, it probably
On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 31 Oct 2007, Nick Piggin wrote:
> >
> > No that would be great. Fingers crossed it won't cause any problems.
>
> I actually doubt it will cause problems.
>
> We made much bi
On Thursday 01 November 2007 12:49, Stefan Richter wrote:
> fw_device.node_id and fw_device.generation are accessed without mutexes.
> We have to ensure that all readers will get to see node_id updates
> before generation updates.
>
Hi, a few points:
- can change it to use spinlocks instead? This
On Thursday 01 November 2007 12:56, bc Wong (chimwong) wrote:
> Hi,
>
> With 2.6.16 x86_64 on a 4 core machine, I noticed
> that the filp usage (according to /proc/slabinfo)
> shoots up and keeps on increasing sharply when one
> of the CPUs is (1) locked up, or (2) very busy
> doing a lot of printk
On Thursday 01 November 2007 20:51, Stefan Richter wrote:
> Nick Piggin wrote:
> > On Thursday 01 November 2007 12:49, Stefan Richter wrote:
> >> fw_device.node_id and fw_device.generation are accessed without mutexes.
> >> We have to ensure that all readers will
On Thursday 01 November 2007 22:56, Romano Giannetti wrote:
> Hi,
>
> I have a very possible regression to signal. This morning 2.6.24-rc1
> eat and destroyed my SD card. I have a toshiba laptop with a card slot
> and I have used it with 2.6.23-rcX and 2.6.23 without problems so far.
> This m
Hi,
I'd like to propose these patches for the x86 tree for a bit more exposure
and testing. Or at least get some discussion going again.
Just for fun I also had a shot at merging the headers, as they become a
lot more similar after this with the removal of the paravirt crud.
Nick
-
To unsubscri
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
is to keep
critical 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/spinlock_64.h
===
--- linux-2.6.orig/include/asm-x
Prepare for merging 32 and 64 bit spinlocks, by making them identical
(except for the OOSTORE thing). raw_read_lock and raw_write_lock get a
relaxed register constraint, and 64-bit has a few "=m" constraints changed
to "+m". I hope these things actually make the code better.
Merge spinlock_32.h and spinlock_64.h into spinlock.h.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/asm-x86/spinlock.h
===
--- linux-2.6.orig/include/asm-x86/spinlock.h
+++ linux-2.6/include/a
On Thu, Nov 01, 2007 at 03:06:05PM +0100, Peter Zijlstra wrote:
> On Thu, 2007-11-01 at 15:02 +0100, Nick Piggin wrote:
>
> > Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
> > decouple it from the spinlock implementation, and make it typesafe (rwloc
On Thu, Nov 01, 2007 at 08:14:47AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 1 Nov 2007, Nick Piggin wrote:
>
> > On Wed, Oct 31, 2007 at 04:08:21PM -0700, Linus Torvalds wrote:
> > >
> > > We made much bigger changes to ptrace support when we disallowe
On Thu, Nov 01, 2007 at 04:46:36PM +0100, Ingo Molnar wrote:
>
> * Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
>
> > > I guess it was done to make the "template" hacks eaiser. I don't
> > > really find that in good taste, especially for important core
> > > infrastructure. Anyway.
> >
> > Actu
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
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
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
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
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
> > >
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
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:
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 &
(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!!
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
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
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
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
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(
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
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
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
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
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
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
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:
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
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:
[...]
__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
--- 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:
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 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
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
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
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
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
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
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
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
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
[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
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
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.
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
[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
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
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
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
[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,
> > >
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
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
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:
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 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
> >
[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
Mathieu Desnoyers wrote:
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxch
Patrick J. LoPresti wrote:
I am using Linux 2.6.16.46-0.12-smp (SUSE 10 SP1 stock kernel).
I do intend to bother SUSE, but I am hoping some kind kernel savant
can help me interpret these log messages and/or give me some
suggestions for how to proceed.
My system is a SunFire x4100 (x86_64) with 1
Daniel Walker wrote:
PICK_FUNCTION() is similar to the other PICK_OP style macros, and was
created to replace them all. I used variable argument macros to handle
PICK_FUNC_2ARG/PICK_FUNC_1ARG. Otherwise the marcos are similar to the
original macros used for semaphores. The entire system is used t
Christoph Hellwig wrote:
On Tue, Aug 28, 2007 at 09:49:38PM +0200, J??rn Engel wrote:
On Tue, 28 August 2007 12:05:58 -0700, [EMAIL PROTECTED] wrote:
- index = *ppos >> PAGE_CACHE_SHIFT;
- offset = *ppos & ~PAGE_CACHE_MASK;
+ index = page_cache_index(mapping, *ppos);
+
Mathieu Desnoyers wrote:
* Nick Piggin ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers wrote:
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned
Mitchell Erblich wrote:
Nick Piggin wrote:
Nick Piggin, et al,
First diffs would generate alot of noise, since I rip and insert
alot of code based on whether I think the code is REALLY
needed for MY TEST environment. These suggestions are
basicly minimal merge
Huang, Ying wrote:
On Mon, 2007-08-27 at 09:28 +0800, Hu, Fenghua wrote:
One quick question is, can it improve hiberation/wakeup time?
In general, for kexec based hibernation, what increases
hibernation/wakeup time:
- One extra Linux boot is needed to hibernate and wakeup.
What decreases
Daniel Phillips wrote:
On Friday 24 August 2007 03:45, Theodore Tso wrote:
As I said; what's wrong with just using SPI membership? It's not
like it is remotely hard for kernel hackers to gain membership in
SPI. And somebody else takes care of the bureaucracy for you.
Given the huge overlap
On Wed, Aug 29, 2007 at 05:39:18PM -0400, Jeff Moyer wrote:
> Nick Piggin <[EMAIL PROTECTED]> writes:
>
> > On Tue, Aug 21, 2007 at 03:48:42PM -0400, Jeff Moyer wrote:
> >> Hi,
> >>
> >> A while back, Nick Piggin introduced a patch to reduce the n
Peter Zijlstra wrote:
On Tue, 2007-08-21 at 16:05 +1000, Dave Airlie wrote:
So you can see why some sort of uncached+writecombined page cache
would be useful, I could just allocate a bunch of pages at startup as
uncached+writecombined, and allocate pixmaps from them and when I
bind/free the pi
On Sat, Sep 01, 2007 at 12:06:03PM -0700, Jason Lunz wrote:
>
> It introduced a wait to read_cache_page, as well as a
> read_cache_page_async function equivalent to the old read_cache_page
> without any callers.
>
> Switching jffs2_gc_fetch_page to read_cache_page_async for the old
> behavior mak
On Sun, Sep 02, 2007 at 01:13:23PM +0100, David Woodhouse wrote:
> Jason, thank you _so_ much for finding the underlying cause of this.
>
> On Sun, 2007-09-02 at 06:20 +0200, Nick Piggin wrote:
> > Hmm, thanks for that. It does sound like it is deadlocking via
> > commit_wr
On Sun, Sep 02, 2007 at 02:48:04PM +0100, David Woodhouse wrote:
> On Sun, 2007-09-02 at 15:20 +0200, Nick Piggin wrote:
> > OK, but then hasn't the patch just made the deadlock harder to hit,
> > or is there some invariant that says that readpage() will never be
> > in
Hi,
This is my "data structure switch" algorithm that can convert one data
structure into another, with just a single unlikely branch in fastpaths
and no locking or atomic operations (the branch is only triggered when
the data structure is in the process of being converted). A pointer
indirection
Dumb, slightly incomplete, dynamic pidhash resizing. I'm just sending this
as a reference and testing tool. While the pid-hash might be the least
problematic one we have, RAM saving / collision minimisation aren't the
only reasons to size a hash optimally: in a really lookup intensive
workload, a s
On Wed, Sep 05, 2007 at 03:42:35AM -0700, Christoph Lameter wrote:
> On Wed, 5 Sep 2007, Daniel Phillips wrote:
>
> > If we remove our anti-deadlock measures, including the ddsnap.vm.fixes
> > (a roll-up of Peter's patch set) and the request throttling code in
> > dm-ddsnap.c, and apply your pat
701 - 800 of 1974 matches
Mail list logo
