On Fri, Feb 08, 2008 at 09:24:22AM +0100, Jens Axboe wrote:
On Fri, Feb 08 2008, Nick Piggin wrote:
On Fri, Feb 08, 2008 at 08:59:55AM +0100, Jens Axboe wrote:
On Fri, Feb 08 2008, Nick Piggin wrote:
And if you don't?
Well if you don't ask for anything, you wont get anything
On Fri, Feb 08, 2008 at 07:09:07AM -0800, Arjan van de Ven wrote:
David Miller wrote:
From: Linus Torvalds [EMAIL PROTECTED]
Date: Thu, 7 Feb 2008 09:42:56 -0800 (PST)
Can we please just stop doing these one-by-one assignments, and just do
something like
memset(rq, 0, sizeof(*rq));
On Fri, Feb 08, 2008 at 08:47:47AM +0100, Jens Axboe wrote:
> On Fri, Feb 08 2008, Nick Piggin wrote:
> > On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote:
> > > Hi,
> > >
> > > Here's a variant using kernel threads only, the nasty arch bits are
On Tue, Feb 05, 2008 at 11:14:19AM +1100, David Chinner wrote:
> On Mon, Feb 04, 2008 at 11:09:59AM +0100, Nick Piggin wrote:
> > You get better behaviour in the slab and page allocators and locality
> > and cache hotness of memory. For example, I guess in a filesystem /
>
On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote:
> Hi,
>
> Here's a variant using kernel threads only, the nasty arch bits are then
> not needed. Works for me, no performance testing (that's a hint for Alan
> to try and queue up some testing for this variant as well :-)
Well this
On Friday 08 February 2008 13:13, Christoph Lameter wrote:
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus
>
> (includes the cmpxchg_local fastpath since the cmpxchg_local work
> by Matheiu is in now, and the non atomic
On Friday 08 February 2008 13:13, Christoph Lameter wrote:
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/christoph/vm.git slub-linus
(includes the cmpxchg_local fastpath since the cmpxchg_local work
by Matheiu is in now, and the non atomic unlock by
On Thu, Feb 07, 2008 at 07:25:45PM +0100, Jens Axboe wrote:
Hi,
Here's a variant using kernel threads only, the nasty arch bits are then
not needed. Works for me, no performance testing (that's a hint for Alan
to try and queue up some testing for this variant as well :-)
Well this stuff
On Tuesday 05 February 2008 11:32, Christoph Lameter wrote:
> On Tue, 5 Feb 2008, Nick Piggin wrote:
> > Ok. But the approach is just not so good. If you _really_ need something
> > like that and it is a win over the regular non-atomic unlock, then you
> > just have to impl
On Tuesday 05 February 2008 10:47, Christoph Lameter wrote:
> On Tue, 5 Feb 2008, Nick Piggin wrote:
> > > erk, sorry, I misremembered. I was about to merge all the patches we
> > > weren't going to merge. oops.
> >
> > While you're there, can yo
On Tuesday 05 February 2008 09:30, Andrew Morton wrote:
> On Mon, 4 Feb 2008 14:28:45 -0800
>
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > root (1):
> > > SLUB: Do not upset lockdep
> >
> > err, what? I though I was going to merge these:
> >
> > slub-move-count_partial.patch
> >
On Tuesday 05 February 2008 01:49, Mike Galbraith wrote:
> On Tue, 2008-01-22 at 06:47 +0100, Mike Galbraith wrote:
> > On Tue, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > On Tuesday 22 January 2008 16:03, Mike Galbraith wrote:
> > > > I've hi
On Monday 04 February 2008 08:21, Robin Lee Powell wrote:
> I've got a machine with a 4 disk SATA raid10 configuration using md.
> The entire disk is loop-AES encrypted, but that shouldn't matter
> here.
>
> Once a month, Debian runs:
>
> /usr/share/mdadm/checkarray --cron --all --quiet
>
>
On Mon, Feb 04, 2008 at 11:12:44AM +0100, Jens Axboe wrote:
> On Sun, Feb 03 2008, Nick Piggin wrote:
> > On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
> >
> > Hi guys,
> >
> > Just had another way we might do this. Migrate the completions out to
&g
On Mon, Feb 04, 2008 at 03:40:20PM +1100, David Chinner wrote:
> On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote:
> > David Chinner wrote:
> > >Hi Nick,
> > >
> > >When Matthew was describing this work at an LCA presentation (not
> > >sure whether you were at that presentation or
On Mon, Feb 04, 2008 at 03:40:20PM +1100, David Chinner wrote:
On Sun, Feb 03, 2008 at 08:14:45PM -0800, Arjan van de Ven wrote:
David Chinner wrote:
Hi Nick,
When Matthew was describing this work at an LCA presentation (not
sure whether you were at that presentation or not), Zach came
On Mon, Feb 04, 2008 at 11:12:44AM +0100, Jens Axboe wrote:
On Sun, Feb 03 2008, Nick Piggin wrote:
On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
Hi guys,
Just had another way we might do this. Migrate the completions out to
the submitting CPUs rather than migrate
On Monday 04 February 2008 08:21, Robin Lee Powell wrote:
I've got a machine with a 4 disk SATA raid10 configuration using md.
The entire disk is loop-AES encrypted, but that shouldn't matter
here.
Once a month, Debian runs:
/usr/share/mdadm/checkarray --cron --all --quiet
and the
On Tuesday 05 February 2008 01:49, Mike Galbraith wrote:
On Tue, 2008-01-22 at 06:47 +0100, Mike Galbraith wrote:
On Tue, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
On Tuesday 22 January 2008 16:03, Mike Galbraith wrote:
I've hit same twice recently (not pan, and not repeatable
On Tuesday 05 February 2008 10:47, Christoph Lameter wrote:
On Tue, 5 Feb 2008, Nick Piggin wrote:
erk, sorry, I misremembered. I was about to merge all the patches we
weren't going to merge. oops.
While you're there, can you drop the patch(es?) I commented on
and didn't get
On Tuesday 05 February 2008 09:30, Andrew Morton wrote:
On Mon, 4 Feb 2008 14:28:45 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
root (1):
SLUB: Do not upset lockdep
err, what? I though I was going to merge these:
slub-move-count_partial.patch
On Tuesday 05 February 2008 11:32, Christoph Lameter wrote:
On Tue, 5 Feb 2008, Nick Piggin wrote:
Ok. But the approach is just not so good. If you _really_ need something
like that and it is a win over the regular non-atomic unlock, then you
just have to implement it as a generic locking
On Sun, Feb 03, 2008 at 12:53:02PM +0200, Pekka Enberg wrote:
> Hi Nick,
>
> On Feb 3, 2008 11:52 AM, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > +asmlinkage void smp_call_function_fast_interrupt(void)
> > +{
>
> [snip]
>
> > + while (!
On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
>
> Second experiment which we did was migrating the IO submission to the
> IO completion cpu. Instead of submitting the IO on the same cpu where the
> request arrived, in this experiment the IO submission gets migrated to the
> cpu that
On Fri, Jul 27, 2007 at 06:21:28PM -0700, Suresh B wrote:
Second experiment which we did was migrating the IO submission to the
IO completion cpu. Instead of submitting the IO on the same cpu where the
request arrived, in this experiment the IO submission gets migrated to the
cpu that is
On Sun, Feb 03, 2008 at 12:53:02PM +0200, Pekka Enberg wrote:
Hi Nick,
On Feb 3, 2008 11:52 AM, Nick Piggin [EMAIL PROTECTED] wrote:
+asmlinkage void smp_call_function_fast_interrupt(void)
+{
[snip]
+ while (!list_empty(list)) {
+ struct call_single_data *data
On Saturday 02 February 2008 20:51, Denis Cheng wrote:
> Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
Thanks, but already patched in -mm.
> ---
> drivers/uio/uio.c | 19 ---
> 1 files changed, 8 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/uio/uio.c
On Saturday 02 February 2008 20:51, Denis Cheng wrote:
Signed-off-by: Denis Cheng [EMAIL PROTECTED]
Thanks, but already patched in -mm.
---
drivers/uio/uio.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
, is used by a lot of drivers, and doesn't cost much to
> maintain.
> Who: Nick Piggin <[EMAIL PROTECTED]>
Well the in-kernel callers have not all been converted yet. I have
actually done the work, but it needs testing and merging by maintainers.
Getting it done during this merge w
On Friday 01 February 2008 21:31, Jens Axboe wrote:
> On Fri, Feb 01 2008, Jens Axboe wrote:
> > I think the right solution is to remove swap_io_context() and fix the io
> > context referencing in as-iosched.c instead.
>
> IOW, the below. I don't know why Nick originally wanted to swap io
>
On Friday 01 February 2008 09:45, Frederik Himpe wrote:
> On ma, 2008-01-28 at 12:46 +1100, Nick Piggin wrote:
> > On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> > > On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > > > On Tuesday 22 Janu
On Friday 01 February 2008 09:45, Frederik Himpe wrote:
On ma, 2008-01-28 at 12:46 +1100, Nick Piggin wrote:
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
On Tuesday 22 January 2008 07:58, Frederik Himpe wrote
On Friday 01 February 2008 21:31, Jens Axboe wrote:
On Fri, Feb 01 2008, Jens Axboe wrote:
I think the right solution is to remove swap_io_context() and fix the io
context referencing in as-iosched.c instead.
IOW, the below. I don't know why Nick originally wanted to swap io
contexts for
of drivers, and doesn't cost much to
maintain.
Who: Nick Piggin [EMAIL PROTECTED]
Well the in-kernel callers have not all been converted yet. I have
actually done the work, but it needs testing and merging by maintainers.
Getting it done during this merge window would be nice, I'm going to
try
Sorry, way behind on email here. I'll get through it slowly...
On Sat, Jan 26, 2008 at 10:03:56PM -0800, Andrew Morton wrote:
> > On Tue, 22 Jan 2008 05:01:14 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > After running SetPageUptodate, preceeding sto
On Thu, Jan 31, 2008 at 11:24:54AM +0100, Ingo Molnar wrote:
>
> * Martin Schwidefsky <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2008-01-31 at 02:33 +0200, Adrian Bunk wrote:
> > > <-- snip -->
> > >
> > > ...
> > > CC arch/s390/kernel/asm-offsets.s
> > > In file included from
> > >
Sorry, way behind on email here. I'll get through it slowly...
On Sat, Jan 26, 2008 at 10:03:56PM -0800, Andrew Morton wrote:
On Tue, 22 Jan 2008 05:01:14 +0100 Nick Piggin [EMAIL PROTECTED] wrote:
After running SetPageUptodate, preceeding stores to the page contents to
actually bring
On Thu, Jan 31, 2008 at 11:24:54AM +0100, Ingo Molnar wrote:
* Martin Schwidefsky [EMAIL PROTECTED] wrote:
On Thu, 2008-01-31 at 02:33 +0200, Adrian Bunk wrote:
-- snip --
...
CC arch/s390/kernel/asm-offsets.s
In file included from
ork is done so I guess I should send it along.
The minix filesystem uses bkl to protect access to metadata. Switch
to a per-superblock mutex.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/fs/minix/bitmap.c
===
On Sunday 27 January 2008 01:27, Pascal Terjan wrote:
> Nick Piggin yahoo.com.au> writes:
> > On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> > > I just succeeded to reproduce the problem with this patch. Does this
> > > smell like an XFS problem?
>
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > &
On Sunday 27 January 2008 17:03, Andrew Morton wrote:
> > On Fri, 25 Jan 2008 14:03:25 +0800 Shaohua Li <[EMAIL PROTECTED]>
> > wrote:
> >
> > - if (!page->mapping)
> > + if (!page->mapping) {
> > + if (!PageAnon(page) && PagePrivate(page))
> > +
On Sunday 27 January 2008 01:27, Pascal Terjan wrote:
Nick Piggin nickpiggin at yahoo.com.au writes:
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
I just succeeded to reproduce the problem with this patch. Does this
smell like an XFS problem?
I got the same issue using ext3
access to metadata. Switch
to a per-superblock mutex.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Index: linux-2.6/fs/minix/bitmap.c
===
--- linux-2.6.orig/fs/minix/bitmap.c
+++ linux-2.6/fs/minix/bitmap.c
@@ -69,11 +69,11 @@ void
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
> On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
> > > > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > &
On Sunday 27 January 2008 00:29, Frederik Himpe wrote:
On di, 2008-01-22 at 16:25 +1100, Nick Piggin wrote:
On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
With Linux 2.6.24-rc8 I often have the problem that the pan usenet
reader starts using 100% of CPU time after some time
On Saturday 26 January 2008 02:03, Asbjørn Sannes wrote:
> Asbjørn Sannes wrote:
> > Nick Piggin wrote:
> >> On Friday 25 January 2008 22:32, Asbjorn Sannes wrote:
> >>> Hi,
> >>>
> >>> I am experiencing unpredictable results with the following
On Friday 25 January 2008 22:32, Asbjorn Sannes wrote:
> Hi,
>
> I am experiencing unpredictable results with the following test
> without other processes running (exception is udev, I believe):
> cd /usr/src/test
> tar -jxf ../linux-2.6.22.12
> cp ../working-config linux-2.6.22.12/.config
> cd
On Friday 25 January 2008 19:15, Jan Beulich wrote:
> Actually, another thought: permitting (and handling) spurious faults for
> kernel mappings conflicts with NMI handling, i.e. great care would be
> needed to ensure the NMI path cannot touch any such mapping. So
> even the present Xen/Linux Dom0
On Thursday 24 January 2008 02:48, Jan Kara wrote:
> On Thu 24-01-08 02:05:16, Nick Piggin wrote:
> > On Thursday 24 January 2008 00:30, Jan Kara wrote:
> > > On Wed 23-01-08 12:00:02, Nick Piggin wrote:
> > > > On Wednesday 23 January 2008 04:10,
On Thursday 24 January 2008 02:48, Jan Kara wrote:
On Thu 24-01-08 02:05:16, Nick Piggin wrote:
On Thursday 24 January 2008 00:30, Jan Kara wrote:
On Wed 23-01-08 12:00:02, Nick Piggin wrote:
On Wednesday 23 January 2008 04:10, Jan Kara wrote:
Hi,
as I got no answer
On Friday 25 January 2008 19:15, Jan Beulich wrote:
Actually, another thought: permitting (and handling) spurious faults for
kernel mappings conflicts with NMI handling, i.e. great care would be
needed to ensure the NMI path cannot touch any such mapping. So
even the present Xen/Linux Dom0
On Saturday 26 January 2008 02:03, Asbjørn Sannes wrote:
Asbjørn Sannes wrote:
Nick Piggin wrote:
On Friday 25 January 2008 22:32, Asbjorn Sannes wrote:
Hi,
I am experiencing unpredictable results with the following test
without other processes running (exception is udev, I believe
On Friday 25 January 2008 14:09, Shaohua Li wrote:
> On Fri, 2008-01-25 at 14:03 +1100, Nick Piggin wrote:
> > On Wednesday 23 January 2008 17:22, Shaohua Li wrote:
> > > Anonymous page might have fs-private metadata, the page is truncated.
> > > As the page hasn't map
it is OK by me.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wednesday 23 January 2008 17:22, Shaohua Li wrote:
> Anonymous page might have fs-private metadata, the page is truncated. As
> the page hasn't mapping, page migration refuse to migrate the page. It
> appears the page is only freed in page reclaim and if zone watermark is
> low, the page is
On Friday 25 January 2008 06:21, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > There's perhaps an opportunity to do this lazy TLB trick in the mmap
> > path as well, where RW mappings are initially mapped as RO so we can
> > catch processes dirtying them and then switched to RW. If the
On Friday 25 January 2008 06:21, Jeremy Fitzhardinge wrote:
Matt Mackall wrote:
There's perhaps an opportunity to do this lazy TLB trick in the mmap
path as well, where RW mappings are initially mapped as RO so we can
catch processes dirtying them and then switched to RW. If the mapping is
On Wednesday 23 January 2008 17:22, Shaohua Li wrote:
Anonymous page might have fs-private metadata, the page is truncated. As
the page hasn't mapping, page migration refuse to migrate the page. It
appears the page is only freed in page reclaim and if zone watermark is
low, the page is never
.
Acked-by: Nick Piggin [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Friday 25 January 2008 14:09, Shaohua Li wrote:
On Fri, 2008-01-25 at 14:03 +1100, Nick Piggin wrote:
On Wednesday 23 January 2008 17:22, Shaohua Li wrote:
Anonymous page might have fs-private metadata, the page is truncated.
As the page hasn't mapping, page migration refuse to migrate
ck_64.o copy_user_nocache_64.o gup.o
Index: linux-2.6/arch/x86/lib/gup.c
===
--- /dev/null
+++ linux-2.6/arch/x86/lib/gup.c
@@ -0,0 +1,189 @@
+/*
+ * Lockless fast_gup for x86
+ *
+ * Copyright (C) 2007 Nick Piggin
+ * Copyright (C) 20
On Thursday 24 January 2008 11:54, 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.
>
> An earlier incarnation of this patch fixes an inability to
On Thursday 24 January 2008 04:05, Linus Torvalds wrote:
> On Wed, 23 Jan 2008, Anton Salikhmetov wrote:
> > +
> > + if (pte_dirty(*pte) && pte_write(*pte)) {
>
> Not correct.
>
> You still need to check "pte_present()" before you can test any other
> bits. For a non-present pte, none of
On Thursday 24 January 2008 00:30, Jan Kara wrote:
> On Wed 23-01-08 12:00:02, Nick Piggin wrote:
> > On Wednesday 23 January 2008 04:10, Jan Kara wrote:
> > > Hi,
> > >
> > > as I got no answer for a week, I'm resending this fix for races in
> > &g
On Thursday 24 January 2008 00:30, Jan Kara wrote:
On Wed 23-01-08 12:00:02, Nick Piggin wrote:
On Wednesday 23 January 2008 04:10, Jan Kara wrote:
Hi,
as I got no answer for a week, I'm resending this fix for races in
private_list handling. Andrew, do you like them more than
On Thursday 24 January 2008 04:05, Linus Torvalds wrote:
On Wed, 23 Jan 2008, Anton Salikhmetov wrote:
+
+ if (pte_dirty(*pte) pte_write(*pte)) {
Not correct.
You still need to check pte_present() before you can test any other
bits. For a non-present pte, none of the other
On Thursday 24 January 2008 11:54, 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.
An earlier incarnation of this patch fixes an inability to recognize
===
--- /dev/null
+++ linux-2.6/arch/x86/lib/gup.c
@@ -0,0 +1,189 @@
+/*
+ * Lockless fast_gup for x86
+ *
+ * Copyright (C) 2007 Nick Piggin
+ * Copyright (C) 2007 Novell Inc.
+ */
+#include linux/sched.h
+#include linux/mm.h
+#include linux
On Wednesday 23 January 2008 09:44, Arjan van de Ven wrote:
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> Subject: x86: test case for the RODATA config option
>
> This patch adds a test module for the DEBUG_RODATA config
> option to make sure change_page_attr() did indeed make
> "const" data read
On Tuesday 22 January 2008 21:37, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Well I've twice tried to submit a patch to print stacks for running
> > tasks as well, but nobody seems interested. It would at least give a
> > chance to see something.
&
On Wednesday 23 January 2008 04:10, Jan Kara wrote:
> Hi,
>
> as I got no answer for a week, I'm resending this fix for races in
> private_list handling. Andrew, do you like them more than the previous
> version?
FWIW, I reviewed this, and it looks OK although I think some comments
would be
On Tuesday 22 January 2008 21:37, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Well I've twice tried to submit a patch to print stacks for running
tasks as well, but nobody seems interested. It would at least give a
chance to see something.
i definitely remembering having
On Wednesday 23 January 2008 04:10, Jan Kara wrote:
Hi,
as I got no answer for a week, I'm resending this fix for races in
private_list handling. Andrew, do you like them more than the previous
version?
FWIW, I reviewed this, and it looks OK although I think some comments
would be in
On Wednesday 23 January 2008 09:44, Arjan van de Ven wrote:
From: Arjan van de Ven [EMAIL PROTECTED]
Subject: x86: test case for the RODATA config option
This patch adds a test module for the DEBUG_RODATA config
option to make sure change_page_attr() did indeed make
const data read only.
On Tuesday 22 January 2008 16:03, Mike Galbraith wrote:
> On Tue, 2008-01-22 at 11:05 +1100, Nick Piggin wrote:
> > On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> > > With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> > > reader starts using
filesystems and at least
some would need reworking. That's great you're interested, I'm eagerly awaiting
your patches.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/include/linux/highmem.h
===
--- linux-2.
On Tuesday 22 January 2008 12:13, Nick Piggin wrote:
> On Tuesday 22 January 2008 07:14, Ingo Molnar wrote:
> > Nick Piggin (5):
> > mm: fix PageUptodate memory ordering bug
>
> This should actually be named differently. It should be
> called
>
> x86: don't un
On Tuesday 22 January 2008 07:14, Ingo Molnar wrote:
> Nick Piggin (5):
> mm: fix PageUptodate memory ordering bug
This should actually be named differently. It should be
called
x86: don't unconditionally enable expensive SMP ppro workaround
I actually had a more complete patch
On Tuesday 22 January 2008 02:22, Steven Rostedt wrote:
> From: john stultz <[EMAIL PROTECTED]>
> static inline cycle_t
> -clocksource_get_cycles(struct clocksource *cs, cycle_t now)
> +clocksource_get_basecycles(struct clocksource *cs)
> {
> - cycle_t offset = (now - cs->cycle_last) &
On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
> With Linux 2.6.24-rc8 I often have the problem that the pan usenet
> reader starts using 100% of CPU time after some time. When this happens,
> kill -9 does not work, and strace just hangs when trying to attach to
> the process. The same
On Tuesday 22 January 2008 02:22, Steven Rostedt wrote:
From: john stultz [EMAIL PROTECTED]
static inline cycle_t
-clocksource_get_cycles(struct clocksource *cs, cycle_t now)
+clocksource_get_basecycles(struct clocksource *cs)
{
- cycle_t offset = (now - cs-cycle_last) cs-mask;
-
On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
With Linux 2.6.24-rc8 I often have the problem that the pan usenet
reader starts using 100% of CPU time after some time. When this happens,
kill -9 does not work, and strace just hangs when trying to attach to
the process. The same with
On Tuesday 22 January 2008 07:14, Ingo Molnar wrote:
Nick Piggin (5):
mm: fix PageUptodate memory ordering bug
This should actually be named differently. It should be
called
x86: don't unconditionally enable expensive SMP ppro workaround
I actually had a more complete patch which
On Tuesday 22 January 2008 12:13, Nick Piggin wrote:
On Tuesday 22 January 2008 07:14, Ingo Molnar wrote:
Nick Piggin (5):
mm: fix PageUptodate memory ordering bug
This should actually be named differently. It should be
called
x86: don't unconditionally enable expensive SMP ppro
On Tuesday 22 January 2008 16:03, Mike Galbraith wrote:
On Tue, 2008-01-22 at 11:05 +1100, Nick Piggin wrote:
On Tuesday 22 January 2008 07:58, Frederik Himpe wrote:
With Linux 2.6.24-rc8 I often have the problem that the pan usenet
reader starts using 100% of CPU time after some time
On Thu, Jan 17, 2008 at 08:39:23PM -0600, Matt Mackall wrote:
>
> On Thu, 2008-01-17 at 18:28 -0800, Andrew Morton wrote:
> > On Fri, 18 Jan 2008 02:02:17 + Byron Bradley <[EMAIL PROTECTED]> wrote:
> >
> > > In arch/arm/kernel/setup.c:setup_ramdisk(), rd_size is set from the
> > > boot tags.
On Friday 18 January 2008 17:33, stephane eranian wrote:
> Nick,
> > It is arch specific. If an architecture wants interrupts on during
> > context switch, or runqueue unlocked, then they set it (btw
> > INTERRUPTS_ON_CTXSW also implies UNLOCKED_CTXSW).
>
> Yes , I noticed that. I am only
On Friday 18 January 2008 17:33, stephane eranian wrote:
Nick,
It is arch specific. If an architecture wants interrupts on during
context switch, or runqueue unlocked, then they set it (btw
INTERRUPTS_ON_CTXSW also implies UNLOCKED_CTXSW).
Yes , I noticed that. I am only interested in
On Thu, Jan 17, 2008 at 08:39:23PM -0600, Matt Mackall wrote:
On Thu, 2008-01-17 at 18:28 -0800, Andrew Morton wrote:
On Fri, 18 Jan 2008 02:02:17 + Byron Bradley [EMAIL PROTECTED] wrote:
In arch/arm/kernel/setup.c:setup_ramdisk(), rd_size is set from the
boot tags. The
On Friday 18 January 2008 00:24, Peter Zijlstra wrote:
> [ At the very least CC'ing the scheduler maintainer would be
> helpful :-) ]
>
> On Wed, 2008-01-16 at 16:29 -0800, stephane eranian wrote:
> > Hello,
> >
> > As suggested by people on this list, I have changed perfmon2 to use
> > the high
On Friday 18 January 2008 10:41, Rusty Russell wrote:
> vfs_init_caches_early() does nothing on IA-64 and x86-64 (unless you
> turn off CONFIG_NUMA): hashdist is set by default on these platforms.
>
> Maybe some obscure feature which requires VFS to be set up v. early
> (hence is broken in this
On Friday 18 January 2008 10:41, Rusty Russell wrote:
vfs_init_caches_early() does nothing on IA-64 and x86-64 (unless you
turn off CONFIG_NUMA): hashdist is set by default on these platforms.
Maybe some obscure feature which requires VFS to be set up v. early
(hence is broken in this
On Friday 18 January 2008 00:24, Peter Zijlstra wrote:
[ At the very least CC'ing the scheduler maintainer would be
helpful :-) ]
On Wed, 2008-01-16 at 16:29 -0800, stephane eranian wrote:
Hello,
As suggested by people on this list, I have changed perfmon2 to use
the high resolution
On Thursday 17 January 2008 06:58, Dave Kleikamp wrote:
> On Wed, 2007-12-12 at 16:40 +1100, Nick Piggin wrote:
> > On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
> > > On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
> > > > Anyway, I am hoping that
On Mon, Jan 14, 2008 at 10:14:46AM +0100, Jes Sorensen wrote:
> Nick Piggin wrote:
> >On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
> >>Nick,
> >>
> >>Is this supposed to apply to the latest Linus tree? I applied it here
> >>and the
On Mon, Jan 14, 2008 at 10:14:46AM +0100, Jes Sorensen wrote:
Nick Piggin wrote:
On Fri, Jan 11, 2008 at 03:40:10PM +0100, Jes Sorensen wrote:
Nick,
Is this supposed to apply to the latest Linus tree? I applied it here
and the mspec driver lights up in beautiful fireworks :-( I'll give
On Thursday 17 January 2008 06:58, Dave Kleikamp wrote:
On Wed, 2007-12-12 at 16:40 +1100, Nick Piggin wrote:
On Wednesday 12 December 2007 16:11, Dave Kleikamp wrote:
On Wed, 2007-12-12 at 15:57 +1100, Nick Piggin wrote:
Anyway, I am hoping that someone will one day and test
On Monday 14 January 2008 22:30, Andi Kleen wrote:
> In general there are more scaling problems like this (e.g. it also doesn't
> make sense to scale kernel threads for each CPU thread for example).
I think in a lot of ways, per-CPU kernel threads scale OK. At least
they should mostly be
On Monday 14 January 2008 22:30, Andi Kleen wrote:
In general there are more scaling problems like this (e.g. it also doesn't
make sense to scale kernel threads for each CPU thread for example).
I think in a lot of ways, per-CPU kernel threads scale OK. At least
they should mostly be dynamic,
101 - 200 of 3926 matches
Mail list logo
