On Thu, May 10, 2007 at 03:39:36PM -0400, Mathieu Desnoyers wrote:
> * Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > > > kprobes does this kind of synchronization internally, so the marker
> > > > wrapper should probabl
On Thu, May 10, 2007 at 03:39:36PM -0400, Mathieu Desnoyers wrote:
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
kprobes does this kind of synchronization internally, so the marker
wrapper should probabl aswell.
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > > kprobes does this kind of synchronization internally, so the marker
> > > wrapper should probabl aswell.
> > >
> >
> > The problem appears on heavily loaded systems. Doing 50
On 5/10/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> Huh? You already stated one version of it above, namely updatedb. But
So a swapping problem with updatedb should be unusual and we'd like to see
if we can fix it without resorting to prefetching.
I know the theory behind swap prefetching,
Ray Lee wrote:
>> Huh? You already stated one version of it above, namely updatedb. But
On Thu, May 10, 2007 at 05:04:54PM +1000, Nick Piggin wrote:
> So a swapping problem with updatedb should be unusual and we'd like to see
> if we can fix it without resorting to prefetching.
> I know the
Ray Lee wrote:
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
> On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> You said it helped with the updatedb problem. That says we should
look at
>> why it is going bad first, and for example improve use-once
algorithms.
>>
Ray Lee wrote:
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
Ray Lee wrote:
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
You said it helped with the updatedb problem. That says we should
look at
why it is going bad first, and for example improve use-once
algorithms.
After we do
Ray Lee wrote:
Huh? You already stated one version of it above, namely updatedb. But
On Thu, May 10, 2007 at 05:04:54PM +1000, Nick Piggin wrote:
So a swapping problem with updatedb should be unusual and we'd like to see
if we can fix it without resorting to prefetching.
I know the theory
On 5/10/07, Nick Piggin [EMAIL PROTECTED] wrote:
Huh? You already stated one version of it above, namely updatedb. But
So a swapping problem with updatedb should be unusual and we'd like to see
if we can fix it without resorting to prefetching.
I know the theory behind swap prefetching, and
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
kprobes does this kind of synchronization internally, so the marker
wrapper should probabl aswell.
The problem appears on heavily loaded systems. Doing 50
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Ray Lee wrote:
> On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> You said it helped with the updatedb problem. That says we should look at
>> why it is going bad first, and for example improve use-once algorithms.
>> After we do that, then
On Thursday 10 May 2007 13:48, Ray Lee wrote:
> On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
> > You said it helped with the updatedb problem. That says we should look at
> > why it is going bad first, and for example improve use-once algorithms.
> > After we do that, then swap prefetching
Ray Lee wrote:
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap prefetching might still help, which is fine.
Nick,
On 5/9/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap prefetching might still help, which is fine.
Nick, if you're
Con Kolivas wrote:
On Thursday 10 May 2007 10:05, Nick Piggin wrote:
I'm not the gatekeeper and it is completely up to you whether you want
to work on something or not... but I'm sure you understand where I was
coming from when I suggested it doesn't get merged yet.
No matter how you spin
On Thursday 10 May 2007 10:05, Nick Piggin wrote:
> Con Kolivas wrote:
> > Well how about that? That was the difference with a swap _file_ as I
> > said, but I went ahead and checked with a swap partition as I used to
> > have. I didn't notice, but somewhere in the last few months, swap
> >
Con Kolivas wrote:
Well how about that? That was the difference with a swap _file_ as I said, but
I went ahead and checked with a swap partition as I used to have. I didn't
notice, but somewhere in the last few months, swap prefetch code itself being
unchanged for a year, seems to have been
On Saturday 05 May 2007 18:42, Con Kolivas wrote:
> On Friday 04 May 2007 22:10, Con Kolivas wrote:
> > On Friday 04 May 2007 18:52, Ingo Molnar wrote:
> > > agreed. Con, IIRC you wrote a testcase for this, right? Could you
> > > please send us the results of that testing?
> >
> > Yes, sorry it's
Hugh Dickins wrote:
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a
On Thu, 10 May 2007, Nick Piggin wrote:
> >
> > The filesystem (or page cache) allows pages beyond i_size to come
> > in there? That wasn't a problem before, was it? But now it is?
>
> The filesystem still doesn't, but if i_size is updated after the page
> is returned, we can have a problem
Hugh Dickins wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second
On Wed, 9 May 2007, Nick Piggin wrote:
> Hugh Dickins wrote:
> > On Wed, 2 May 2007, Nick Piggin wrote:
>
> > > >But I'm pretty sure (to use your words!) regular truncate was not racy
> > > >before: I believe Andrea's sequence count was handling that case fine,
> > > >without a second
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
OK, I think you're right. I _think_ it should also
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
OK, I think you're right. I _think_ it should also
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second unmap_mapping_range.
Hugh Dickins wrote:
On Wed, 9 May 2007, Nick Piggin wrote:
Hugh Dickins wrote:
On Wed, 2 May 2007, Nick Piggin wrote:
But I'm pretty sure (to use your words!) regular truncate was not racy
before: I believe Andrea's sequence count was handling that case fine,
without a second
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a problem that was
Hugh Dickins wrote:
On Thu, 10 May 2007, Nick Piggin wrote:
The filesystem (or page cache) allows pages beyond i_size to come
in there? That wasn't a problem before, was it? But now it is?
The filesystem still doesn't, but if i_size is updated after the page
is returned, we can have a
On Saturday 05 May 2007 18:42, Con Kolivas wrote:
On Friday 04 May 2007 22:10, Con Kolivas wrote:
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
agreed. Con, IIRC you wrote a testcase for this, right? Could you
please send us the results of that testing?
Yes, sorry it's a crappy test
Con Kolivas wrote:
Well how about that? That was the difference with a swap _file_ as I said, but
I went ahead and checked with a swap partition as I used to have. I didn't
notice, but somewhere in the last few months, swap prefetch code itself being
unchanged for a year, seems to have been
On Thursday 10 May 2007 10:05, Nick Piggin wrote:
Con Kolivas wrote:
Well how about that? That was the difference with a swap _file_ as I
said, but I went ahead and checked with a swap partition as I used to
have. I didn't notice, but somewhere in the last few months, swap
prefetch code
Con Kolivas wrote:
On Thursday 10 May 2007 10:05, Nick Piggin wrote:
I'm not the gatekeeper and it is completely up to you whether you want
to work on something or not... but I'm sure you understand where I was
coming from when I suggested it doesn't get merged yet.
No matter how you spin
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap prefetching might still help, which is fine.
Nick, if you're
Ray Lee wrote:
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap prefetching might still help, which is fine.
Nick, if
On Thursday 10 May 2007 13:48, Ray Lee wrote:
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap prefetching might still
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
Ray Lee wrote:
On 5/9/07, Nick Piggin [EMAIL PROTECTED] wrote:
You said it helped with the updatedb problem. That says we should look at
why it is going bad first, and for example improve use-once algorithms.
After we do that, then swap
On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
> These ops could also be put to use in bit spinlocks, buffer lock, and
> probably a few other places too.
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little
On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
...
> git-unionfs.patch
>
> Does this have a future?
Yes! There are many active users who use our unioning functionality.
Namespace unification consists of several major parts:
1) Duplicate elimination: This can be handled in the
Con Kolivas wrote:
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
agreed. Con, IIRC you wrote a testcase for this, right? Could you please
send us the results of that testing?
Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
disabled and then enabled swap prefetch
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
i'm wondering about swap-prefetch:
Being able to config all these core heuristics changes is really not
that much of a positive. The fact that we might _need_ to config
something out, and double the configuration range isn't too
Sorry for late response. I went on a vacation in last week.
And I'm in the mountain of a ton of unread mail now
> > Mel's moveable-zone work.
>
> These patches are what creates ZONE_MOVABLE. The last 6 patches should be
> collapsed into a single patch:
>
> handle-kernelcore=-generic
On Mon, Apr 30, 2007 at 04:20:07PM -0700, Andrew Morton wrote:
...
git-unionfs.patch
Does this have a future?
Yes! There are many active users who use our unioning functionality.
Namespace unification consists of several major parts:
1) Duplicate elimination: This can be handled in the
On Fri, 2007-05-04 at 19:23 +1000, Nick Piggin wrote:
These ops could also be put to use in bit spinlocks, buffer lock, and
probably a few other places too.
Ok, the performance hit seems to be under control (especially with the
bigger benchmark showing actual improvements).
There's a little
Sorry for late response. I went on a vacation in last week.
And I'm in the mountain of a ton of unread mail now
Mel's moveable-zone work.
These patches are what creates ZONE_MOVABLE. The last 6 patches should be
collapsed into a single patch:
handle-kernelcore=-generic
I
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
i'm wondering about swap-prefetch:
Being able to config all these core heuristics changes is really not
that much of a positive. The fact that we might _need_ to config
something out, and double the configuration range isn't too
Con Kolivas wrote:
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
agreed. Con, IIRC you wrote a testcase for this, right? Could you please
send us the results of that testing?
Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
disabled and then enabled swap prefetch
Con Kolivas wrote:
> Here's a better swap prefetch tester. Instructions in file.
>
> Machine with 2GB ram and 2GB swapfile
>
> Prefetch disabled:
> ./sp_tester
> Ram 2060352000 Swap 197342
> Total ram to be malloced: 3047062000 bytes
> Starting first malloc of 1523531000 bytes
> Starting 1st
2007/5/5, Con Kolivas <[EMAIL PROTECTED]>:
[cut]
Here's a better swap prefetch tester. Instructions in file.
The system should be leaved totally inactive for the test duration (10m) right?
Regards,
~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
2007/5/5, Con Kolivas [EMAIL PROTECTED]:
[cut]
Here's a better swap prefetch tester. Instructions in file.
The system should be leaved totally inactive for the test duration (10m) right?
Regards,
~ Antonio
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Con Kolivas wrote:
Here's a better swap prefetch tester. Instructions in file.
Machine with 2GB ram and 2GB swapfile
Prefetch disabled:
./sp_tester
Ram 2060352000 Swap 197342
Total ram to be malloced: 3047062000 bytes
Starting first malloc of 1523531000 bytes
Starting 1st read of
On Friday 04 May 2007 22:10, Con Kolivas wrote:
> On Friday 04 May 2007 18:52, Ingo Molnar wrote:
> > agreed. Con, IIRC you wrote a testcase for this, right? Could you please
> > send us the results of that testing?
>
> Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
>
On Friday 04 May 2007 22:10, Con Kolivas wrote:
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
agreed. Con, IIRC you wrote a testcase for this, right? Could you please
send us the results of that testing?
Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
disabled
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
> agreed. Con, IIRC you wrote a testcase for this, right? Could you please
> send us the results of that testing?
Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
disabled and then enabled swap prefetch saves ~5 seconds on
Nick Piggin wrote:
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
Here were some of my concerns, and where our discussion got up to.
Yes. Perhaps it just doesn't help with the updatedb thing. Or
maybe with normal system activity we get enough free pages to kick
the thing off and running.
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > i'm wondering about swap-prefetch:
> Being able to config all these core heuristics changes is really not
> that much of a positive. The fact that we might _need_ to config
> something out, and double the configuration range isn't too pleasing.
Ingo Molnar wrote:
* Andrew Morton <[EMAIL PROTECTED]> wrote:
- If replying, please be sure to cc the appropriate individuals.
Please also consider rewriting the Subject: to something
appropriate.
i'm wondering about swap-prefetch:
Well I had some issues with it that I don't think
Ingo Molnar wrote:
* Andrew Morton [EMAIL PROTECTED] wrote:
- If replying, please be sure to cc the appropriate individuals.
Please also consider rewriting the Subject: to something
appropriate.
i'm wondering about swap-prefetch:
Well I had some issues with it that I don't think were
* Nick Piggin [EMAIL PROTECTED] wrote:
i'm wondering about swap-prefetch:
Being able to config all these core heuristics changes is really not
that much of a positive. The fact that we might _need_ to config
something out, and double the configuration range isn't too pleasing.
Well, to
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
Here were some of my concerns, and where our discussion got up to.
Yes. Perhaps it just doesn't help with the updatedb thing. Or
maybe with normal system activity we get enough free pages to kick
the thing off and running.
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that patch. Then if we have
Nick Piggin wrote:
Nick Piggin wrote:
Christoph Hellwig wrote:
Is that every fork/exec or just under certain cicumstances?
A 5% regression on every fork/exec is not acceptable.
Well after patch2, G5 fork is 3% and exec is 1%, I'd say the P4
numbers will be improved as well with that
On Friday 04 May 2007 18:52, Ingo Molnar wrote:
agreed. Con, IIRC you wrote a testcase for this, right? Could you please
send us the results of that testing?
Yes, sorry it's a crappy test app but works on 32bit. Timed with prefetch
disabled and then enabled swap prefetch saves ~5 seconds on
Andrew Morton wrote:
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
void fastcall unlock_page(struct page *page)
{
+ VM_BUG_ON(!PageLocked(page));
smp_mb__before_clear_bit();
- if (!TestClearPageLocked(page))
- BUG();
-
On Fri, 4 May 2007, Benjamin Herrenschmidt wrote:
> > The SLUB allocator relies on struct page fields first_page and slab,
> > overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
> > be used for the lowest level of pagetable pages. This was obstructing
> > SLUB on PowerPC,
On Thu, 2007-05-03 at 22:04 +0100, Hugh Dickins wrote:
> On Thu, 3 May 2007, Hugh Dickins wrote:
> >
> > Seems we're all wrong in thinking Christoph's Kconfiggery worked
> > as intended: maybe it just works some of the time. I'm not going
> > to hazard a guess as to how to fix it up, will resume
On Thu, 3 May 2007, Christoph Lameter wrote:
>
> There are SLUB patches pending (not in rc7-mm2 as far as I can recall)
> that reduce the default page order sizes to head off this issue. The
> defaults were initially too large (and they still default to large
> for testing if Mel's Antifrag
On Friday 04 May 2007 01:54, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > - If replying, please be sure to cc the appropriate individuals.
> > Please also consider rewriting the Subject: to something
> > appropriate.
> i've reviewed it once again and in the
On Thu, 3 May 2007, Hugh Dickins wrote:
> On Thu, 3 May 2007, Hugh Dickins wrote:
> >
> > Seems we're all wrong in thinking Christoph's Kconfiggery worked
> > as intended: maybe it just works some of the time. I'm not going
> > to hazard a guess as to how to fix it up, will resume looking at
>
On Thu, 3 May 2007, Hugh Dickins wrote:
>
> Seems we're all wrong in thinking Christoph's Kconfiggery worked
> as intended: maybe it just works some of the time. I'm not going
> to hazard a guess as to how to fix it up, will resume looking at
> the powerpc's quicklist potential later.
Here's
On Thu, May 03, 2007 at 01:16:46PM -0400, Mathieu Desnoyers wrote:
> > kprobes does this kind of synchronization internally, so the marker
> > wrapper should probabl aswell.
> >
>
> The problem appears on heavily loaded systems. Doing 50
> synchronize_sched() calls in a row can take up to a few
Here is the reworked patch, except a comment :
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> > +void blk_probe_disconnect(void)
> > +{
> > + uint8_t i;
> > +
> > + for (i = 0; i < NUM_PROBES; i++) {
> > + marker_remove_probe(probe_array[i].name);
> > + }
> > +
On Thu, 03 May 2007 11:32:23 +1000 Nick Piggin <[EMAIL PROTECTED]> wrote:
> void fastcall unlock_page(struct page *page)
> {
> + VM_BUG_ON(!PageLocked(page));
> smp_mb__before_clear_bit();
> - if (!TestClearPageLocked(page))
> - BUG();
> -
H...There are a gazillion configs to choose from. It works fine with
cell_defconfig. If I switch to 2 processors I can enable SLUB if I switch
to 4 I cannot.
I saw some other config weirdness like being unable to set SMP if SLOB is
enabled with some configs. This should not work and does
On Thu, 3 May 2007, William Lee Irwin III wrote:
> I've seen this crash in flush_old_exec() before. ISTR it being due to
> slub vs. pagetable alignment or something on that order.
>From from other discussion regarding SLAB: It may be necessary for
powerpc to set the default alignment to 8 bytes
On 03/05/07, Michal Piotrowski <[EMAIL PROTECTED]> wrote:
Hi,
On 03/05/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > - If replying, please be sure to cc the appropriate individuals.
> > Please also consider rewriting the Subject: to something
Hi,
On 03/05/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> - If replying, please be sure to cc the appropriate individuals.
> Please also consider rewriting the Subject: to something
> appropriate.
i'm wondering about swap-prefetch:
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> - If replying, please be sure to cc the appropriate individuals.
> Please also consider rewriting the Subject: to something
> appropriate.
i'm wondering about swap-prefetch:
mm-implement-swap-prefetching.patch
On Thu, May 03, 2007 at 11:04:15AM -0400, Mathieu Desnoyers wrote:
> - blk_add_trace_rq(q, rq, BLK_TA_INSERT);
> + MARK(blk_request_insert, "%p %p", q, rq);
I don't really like the shouting MARK name very much. Can we have
a less-generic, less shouting name, e.g. trace_marker? The aboe
* Andrew Morton ([EMAIL PROTECTED]) wrote:
> > Although some, like Christoph and myself, think that it would benefit to
> > the kernel community to have a common infrastructure for more than just
> > markers (meaning common serialization and buffering mechanism), it does
> > not change the fact
Hi Andi,
This plan makes sense. I will split the "patched in enabled/disable
flags" part into a separate piece (good idea!) and then submit the LTTng
core to Andrew. Christoph's has a good point about wanting a usable
infrastructure to go ini. Regarding your plan, I must argue that
blktrace is
* Christoph Hellwig ([EMAIL PROTECTED]) wrote:
> On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote:
> > My statement was probably not clear enough. The actual marker code is
> > useful as-is without any further kernel patching required : SystemTAP is
> > an example where they use
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
{
DEFINE_WAIT_BIT(wait, >flags, PG_locked);
+ set_bit(PG_waiters, >flags);
+ if (unlikely(!TestSetPageLocked(page))) {
What happens if another cpu is coming
On Thu, 3 May 2007, Nick Piggin wrote:
> >>@@ -568,6 +570,11 @@ __lock_page (diff -p would tell us!)
> > > {
> > > DEFINE_WAIT_BIT(wait, >flags, PG_locked);
> > >
> > >+ set_bit(PG_waiters, >flags);
> > >+ if (unlikely(!TestSetPageLocked(page))) {
> >
> > What happens if another cpu is coming
Christoph Hellwig wrote:
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
G5
pagefault fork exec
2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
+patch 1.71-1.73
Hugh Dickins wrote:
On Thu, 3 May 2007, Nick Piggin wrote:
The problem is that lock/unlock_page is expensive on powerpc, and
if we improve that, we improve more than just the fault handler...
The attached patch gets performance up a bit by avoiding some
barriers and some cachelines:
On Thu, 3 May 2007, Nick Piggin wrote:
>
> The problem is that lock/unlock_page is expensive on powerpc, and
> if we improve that, we improve more than just the fault handler...
>
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
There's a strong
On Thu, May 03, 2007 at 11:32:23AM +1000, Nick Piggin wrote:
> The attached patch gets performance up a bit by avoiding some
> barriers and some cachelines:
>
> G5
> pagefault fork exec
> 2.6.21 1.49-1.51 164.6-170.8 741.8-760.3
> +patch 1.71-1.73 175.2-180.8
> If we are looking at current "potential users" that are already in
> mainline, we could change blktrace to make it use the markers.
Ok, but do it step by step:
- split out useful pieces like the "patched in enable/disable flags"
and submit them separate with an example user or two
[I got a
On Wed, May 02, 2007 at 11:46:40PM +0200, Tilman Schmidt wrote:
> Am 02.05.2007 19:49 schrieb Andi Kleen:
> > And also I think when something is merged it should have some users in tree.
>
> Isn't that a circular dependency?
The normal mode of operation is to merge the initial users and the
On Thu, 3 May 2007, Andrew Morton wrote:
> On Thu, 3 May 2007 09:46:32 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]>
> wrote:
> > On Thu, 3 May 2007, Andrew Morton wrote:
> > > On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL
> > > PROTECTED]> wrote:
> > >
> > > > +config
On Thu, 3 May 2007 09:46:32 +0100 (BST) Hugh Dickins <[EMAIL PROTECTED]> wrote:
> On Thu, 3 May 2007, Andrew Morton wrote:
> > On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL
> > PROTECTED]> wrote:
> >
> > > +config ARCH_USES_SLAB_PAGE_STRUCT
> > > + bool
> > > + default y
> >
On Thu, 3 May 2007, Andrew Morton wrote:
> On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
> wrote:
>
> > +config ARCH_USES_SLAB_PAGE_STRUCT
> > + bool
> > + default y
> > + depends on SPLIT_PTLOCK_CPUS <= NR_CPUS
> > +
>
> That all seems to work as intended.
On Thu, May 03, 2007 at 01:15:15AM -0700, Andrew Morton wrote:
> That all seems to work as intended.
> However with NR_CPUS=8 SPLIT_PTLOCK_CPUS=4, enabling SLUB=y crashes the
> machine early in boot.
> Too early for netconsole, no serial console. Wedges up uselessly with
> CONFIG_XMON=n, does
On Wed, 2 May 2007 10:25:47 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
> On Wed, 2 May 2007, Hugh Dickins wrote:
>
> > I presume the answer is just to extend your quicklist work to
> > powerpc's lowest level of pagetables. The only other architecture
> > which is using kmem_cache
On Wed, May 02, 2007 at 04:36:27PM -0400, Mathieu Desnoyers wrote:
> The idea is the following : either we integrate the infrastructure for
> instrumentation / data serialization / buffer management / extraction of
> data to user space in multiple different steps, which makes code review
> easier
On Wed, May 02, 2007 at 01:53:36PM -0700, Andrew Morton wrote:
> In which case we have:
>
> atomich-add-atomic64-cmpxchg-xchg-and-add_unless-to-alpha.patch
> atomich-complete-atomic_long-operations-in-asm-generic.patch
> atomich-i386-type-safety-fix.patch
>
On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote:
> My statement was probably not clear enough. The actual marker code is
> useful as-is without any further kernel patching required : SystemTAP is
> an example where they use external modules to load probes that can
> connect
On Wed, May 02, 2007 at 07:11:04PM -0400, Mathieu Desnoyers wrote:
My statement was probably not clear enough. The actual marker code is
useful as-is without any further kernel patching required : SystemTAP is
an example where they use external modules to load probes that can
connect either to
1 - 100 of 332 matches
Mail list logo
