Ben Greear wrote:
Nick Piggin wrote:
Ben Greear wrote:
In that case, writing the network only test would help to confirm the
problem is not a networking one - so not useless by any means.
It's not trivial to write something like this :)
I'll be using something I already have.
Siddha, Suresh B wrote:
Nick,
On Mon, Mar 07, 2005 at 07:28:23PM +1100, Nick Piggin wrote:
Siddha, Suresh B wrote:
We are resetting the nr_balance_failed to cache_nice_tries after kicking
active balancing. But can_migrate_task will succeed only if
nr_balance_failed > cache_nice_tries.
It
Hugh Dickins wrote:
This patch is the odd-one-out of the sequence. The one before adjusted
copy_pte_range from a for loop to a do while loop, and it was therefore
simplest to check for lockbreak before copying pte: possibility that it
might keep getting preempted without making progress under some
Andrew Morton wrote:
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
This could be part of the unknown 2% performance regression with
db transaction processing benchmark.
The four functions in the following patch use to be inline. They
are un-inlined since 2.6.7.
We measured that by re-inline them ba
Arun Srinivas wrote:
few more trivial Q's (bear with me I'm a newbie to kernel world):
1) As I said I have a process that spawns 2 threads(thread A and B).I am
trying to measure the exact time @ which they are being scheduled.For
this I am using the rdtsc() (when threads A and B come) in
enque
David S. Miller wrote:
On Wed, 23 Mar 2005 17:10:15 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
Here's the recut of those patches, including David Miller's vital fixes.
I'm addressing these to Nick rather than Andrew, because they're perhaps
not fit for -mm until more testing done and the
Luck, Tony wrote:
OK, attached is my first cut at slimming down the boundary tests.
I have only had a chance to try it on i386, so I hate to drop it
on you like this - but I *have* put a bit of thought into it
Treat it as an RFC, and I'll try to test it on a wider range of
things in the next co
Blaisorblade wrote:
On Wednesday 23 March 2005 18:09, Bodo Stroesser wrote:
[EMAIL PROTECTED] wrote:
Use rep_nop instead of barrier for cpu_relax, following $(SUBARCH)'s
doing that (i.e. i386 and x86_64).
IIRC, Jeff had the idea, to use sched_yield() for this (from a discussion
on #uml).
Hmm, makes
Hugh Dickins wrote:
And the range to sparc64's flush_tlb_pgtables? It's less clear to me
now that we need to do more than is done here - every PMD_SIZE ever
occupied will be flushed, do we really have to flush every PGDIR_SIZE
ever partially occupied? A shame to complicate it unnecessarily.
It lo
Nick Piggin wrote:
Hugh Dickins wrote:
And the range to sparc64's flush_tlb_pgtables? It's less clear to me
now that we need to do more than is done here - every PMD_SIZE ever
occupied will be flushed, do we really have to flush every PGDIR_SIZE
ever partially occupied? A shame to com
Russell King wrote:
On Wed, Mar 23, 2005 at 05:10:15PM +, Hugh Dickins wrote:
Here's the recut of those patches, including David Miller's vital fixes.
I'm addressing these to Nick rather than Andrew, because they're perhaps
not fit for -mm until more testing done and the x86_64 32-bit vdso issu
Russell King wrote:
On Sat, Mar 26, 2005 at 01:06:47PM +1100, Nick Piggin wrote:
The reject should be confined to include/asm-ia64, so it will still
work for you.
I guess I should've tried a little harder last night then. Sorry.
Well I only said that just in case you had time to try te
Russell King wrote:
Ok. What's happening is that the ARM pgd_alloc uses pte_alloc_map() to
allocate the first L1 page table. This sets mm->nr_ptes to be one.
The ARM free_pgd knows about this, and will free this PTE at the
appropriate time. However, exit_mmap() doesn't know about this itself,
so
Russell King wrote:
On Sun, Mar 27, 2005 at 12:42:56AM +1100, Nick Piggin wrote:
OK, thanks that would be good. You could well be right in your analysis.
May I suggest a possible avenue of investigation:
Yes, this patch seems to also be required, otherwise I see:
[...]
OK.
The above is with my
Paul Jackson wrote:
Stringent enforcement of cpuset memory placement could cause
the kernel to panic on a GFP_ATOMIC (!wait) memory allocation,
even though memory was available elsewhere in the system.
Relax the cpuset constraint, on the last zone loop in
mm/page_alloc.c:__alloc_pages(), for ATOMIC
Nick Piggin wrote:
I haven't used a big disk array (or tried any simulation), but I'll
attach the patch if you're looking into that area.
Oh, and this one removes a memory barrier. I think we (Jens and I)
agreed this is valid. Whether or not you'll notice a difference is
ano
Jens Axboe wrote:
On Mon, Mar 28 2005, Chen, Kenneth W wrote:
This patch was posted last year and if I remember correctly, Jens said
he is OK with the patch. In function __generic_unplug_deivce(), kernel
can use a cheaper function elv_queue_empty() instead of more expensive
elv_next_request to fin
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
The unplug change is a no-brainer.
Yep - I may have even stolen it from you (or someone) from a patch
which had been forgotten. I can't remember for sure, but it is trivial
enough that anyone could co
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
Here is another thing I just noticed that should further reduce the
locking by at least 1, sometimes 2 lock/unlock pairs per request.
At the cost of uglifying the code somewhat. Although it is pretty
Arjan van de Ven wrote:
On Tue, 2005-03-29 at 19:19 +1000, Nick Piggin wrote:
- removes the relock/retry merge mechanism in __make_request if we
aren't able to get the GFP_ATOMIC allocation. Just fall through
and assume the chances of getting a merge will be small (is this
a valid assum
Jens Axboe wrote:
On Tue, Mar 29 2005, Nick Piggin wrote:
@@ -2577,19 +2577,18 @@ static int __make_request(request_queue_
spin_lock_prefetch(q->queue_lock);
barrier = bio_barrier(bio);
- if (barrier && (q->ordered == QUEUE_ORDERED_NONE)) {
+ if (unlikely(
Nick Piggin wrote:
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
Here is another thing I just noticed that should further reduce the
locking by at least 1, sometimes 2 lock/unlock pairs per request.
At the cost of uglifying the code som
Linus Torvalds wrote:
On Tue, 29 Mar 2005, Chen, Kenneth W wrote:
Linus Torvalds wrote on Tuesday, March 29, 2005 4:00 PM
The fact that it seems to fluctuate pretty wildly makes me wonder
how stable the numbers are.
I can't resist myself from bragging. The high point in the fluctuation
might be bec
Chen, Kenneth W wrote:
Nick Piggin wrote on Tuesday, March 29, 2005 5:32 PM
If it is doing a lot of mapping/unmapping (or fork/exit), then that
might explain why 2.6.11 is worse.
Fortunately there are more patches to improve this on the way.
Once benchmark reaches steady state, there is no
Kyle Moffett wrote:
On Mar 30, 2005, at 18:38, Jakub Jelinek wrote:
This testcase violates ISO C99 6.3.2.3:
If a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.
Except that
Chen, Kenneth W wrote:
Linus Torvalds wrote on Thursday, March 31, 2005 12:09 PM
Btw, I realize that you can't give good oprofiles for the user-mode
components, but a kernel profile with even just single "time spent in user
mode" datapoint would be good, since a kernel scheduling problem might
just
linux-os wrote:
For those interested, some file-system tests and a test-tools
are attached.
I'll give it a run when I get a chance. Thanks.
In the meantime, can you try with different io schedulers?
Also, my .signature disappeared during the file-system tests.
There were no errors and e2fsck thinks
On Thu, 2005-03-31 at 22:05 -0800, Paul Jackson wrote:
>
> Then us poor slobs with big honkin numa iron could code up a real
> pseudo_distance() routine, to avoid the actual pain of doing real work
> for cpus^2 iterations for large cpu counts.
>
> Our big boxes have regular geometries with much s
Siddha, Suresh B wrote:
Appended patch removes the unnecessary scheduler domains(containing
only one sched group) setup during the sched-domain init.
For example on x86_64, we always have NUMA configured in. On Intel EM64T
systems, top most sched domain will be of NUMA and with only one sched_group
Chen, Kenneth W wrote:
Ingo Molnar wrote on Thursday, March 31, 2005 8:52 PM
the current defaults for cache_hot_time are 10 msec for NUMA domains,
and 2.5 msec for SMP domains. Clearly too low for CPUs with 9MB cache.
Are you increasing cache_hot_time in your experiment? If that solves
most of the
Linus Torvalds wrote:
On Fri, 1 Apr 2005, Chen, Kenneth W wrote:
Paul, you definitely want to check this out on your large numa box. I booted
a kernel with this patch on a 32-way numa box and it took a long time
to produce the cost matrix.
Is there anything fundamentally wrong with the notio
Siddha, Suresh B wrote:
This time Ken Chen brought up this issue -- No it has nothing to do with
industry db benchmark ;-)
Even with the above mentioned Nick's patch in -mm, I see system livelock's
if for example I have 7000 processes pinned onto one cpu (this is on the
fastest 8-way system I
ally slow bitflag). This eliminates one bus locked
memory operation when context switching, and simplifies the task_running
function.
Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Index: linux-2.6/kernel/sched.c
===
--- linux
Haven't finished (hardly started) the arch code for this yet (and probably
broke ppc64), so it is just an RFC at this stage.
The large CC list is because it is a reasonably big change, so I hope one
or two of you smart guys can see if it looks sound before I try to tackle
the rest of the arch code
Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 12:07:27PM +1000, Nick Piggin wrote:
I was thinking we could fix that by running balance on fork/exec multiple
times from top to bottom level domains. I'll have to measure the cost of
doing that, because it may be worthwhile.
Agreed.
BTW, why a
Siddha, Suresh B wrote:
On Sat, Apr 02, 2005 at 01:11:20PM +1000, Nick Piggin wrote:
How important is this? Any application to real workloads? Even if
not, I agree it would be nice to improve this more. I don't know
if I really like this approach - I guess due to what it adds to
fastpaths.
David Lang wrote:
On Sat, 2 Apr 2005, Andreas Dilger wrote:
given that this would let you get the same storage with about 1200
fewer
drives (with corresponding savings in raid controllers, fiberchannel
controllers and rack frames) it would be interesting to know how
close it
would be (for a lot o
Nick Piggin wrote:
This actually improves performance noticably (ie. a % or so) on schedule /
wakeup happy benchmarks (tbench, on a dual Xeon with HT using mwait idle).
Here are some numbers on a 2 socket Xeon with HT and mwait idle.
Average of 3 runs, tbench, single client and single server
Paul Jackson wrote:
Ingo wrote:
if you create a sched-domains hierarchy (based on the SLIT tables, or in
whatever other way) that matches the CPU hierarchy then you'll
automatically get the proper distances detected.
Yes - agreed. I should push in the direction of improving the
SN2 sched domain
On Sun, 2005-04-03 at 20:55 -0700, Paul Jackson wrote:
> But if we knew the CPU hierarchy in more detail, and if we had some
> other use for that detail (we don't that I know), then I take it from
> your comment that we should be reluctant to push those details into the
> sched domains. Put them
William Lee Irwin III wrote:
On Mon, Jan 17, 2005 at 03:30:23PM -0200, Marcelo Tosatti wrote:
You want to update your patch to handle the new 4level pagetables
which introduces a new indirection table: the PUD.
Check 2.6.11-rc1 - mm/rmap.c.
BTW: What does PUD stand for?
Page Upper Directory.
Tha
Linus Torvalds wrote:
On Tue, 18 Jan 2005, Luck, Tony wrote:
David Mosberger:
So, when we run bw_pipe on a low load SMP machine, the kernel running in
a way load balancer always trying to spread out 2 processes while the
wake_up_interruptible_sync() is always trying to draw them back into
1 cpu.
Li
David Mosberger wrote:
On Wed, 19 Jan 2005 10:34:30 +1100, Nick Piggin <[EMAIL PROTECTED]> said:
Nick> David I remember you reporting a pipe bandwidth regression,
Nick> and I had a patch for it, but that hurt other workloads, so I
Nick> don't think we ever really got any
Nick Piggin wrote:
William Lee Irwin III wrote:
It also is used in a particular euphemism that made
it seem odd to me. I suspect it wasn't thought of when it was chosen.
No. What's the euphemism?
... a few private responses later...
Thanks for the enlightenment, everyone. Next ti
David Howells wrote:
Dominik Brodowski <[EMAIL PROTECTED]> wrote:
Add functions down_read_interruptible, and down_write_interruptible to rw
semaphores. Implement these for i386.
...
+static inline int
+rwsem_down_interruptible_failed_common(struct rw_semaphore *sem,
+ struct
On Thu, 2005-01-20 at 22:20 -0800, Andrew Morton wrote:
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
> >
> > This is the forward port to 2.6 of the lowmem_reserved algorithm I
> > invented in 2.4.1*, merged in 2.4.2x already and needed to fix workloads
> > like google (especially without swap)
On Thu, 2005-01-20 at 22:46 -0800, Andrew Morton wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> > It does turn on lowmem protection by default. We never reached
> > an agreement about doing this though, but Andrea has shown that
> > it fixes trivial OOM cases.
&g
Zou Nan hai wrote:
Hi,
There is a bug in copy_page_range in current 2.6.11-rc1 with 4 level
page table change. copy_page_range do a continue without adding pgds and
addr when pgd_none(*src_pgd) or pgd_bad(*src_pgd).
I think it's wrong in logic, copy_page_range will run into infinite loop
when whe
Jack O'Quin wrote:
Chris Wright and Arjan van de Ven have outlined a proposal to address
the privilege issue using rlimits. This is still the only workable
alternative to the realtime LSM on the table. If the decision were up
to me, I would choose the simplicity and better security of the LSM.
Bu
Paolo Ciarrocchi wrote:
On Mon, 24 Jan 2005 09:59:02 +0100, Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...]
- CKRM is another possibility, and has nonzero costs as well, but solves
a wider range of problems.
BTW, do you know what's the status of CKRM ?
If I'm not wrong it is already widely used, is t
Jack O'Quin wrote:
Ingo Molnar <[EMAIL PROTECTED]> writes:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
amount of CPU time all RT tasks combined may use, in percent. Defaults
to 80%.
just apply the patch to 2.6.11-rc2 and you shoul
Andrew Tridgell wrote:
Andrew,
> So what you should do before generating the leak tool output is to put
> heavy memory pressure on the machine to try to get it to free up as much of
> that pagecache as possible. bzero(malloc(lots)) will do it - create a real
> swapstorm, then do swapoff to kil
[Hi, please cc Andi on 4 level page tables stuff too]
Anton Blanchard wrote:
Hi,
The 4 level pagetable code changed the exit_mmap code to rely on
TASK_SIZE. On some architectures (eg ppc64 and ia64), this is a per task
property and bad things can happen in certain circumstances when using
it.
It is
: Nick Piggin <[EMAIL PROTECTED]>
---
Index: linux-2.6/mm/vmscan.c
===
--- linux-2.6.orig/mm/vmscan.c
+++ linux-2.6/mm/vmscan.c
@@ -589,7 +589,14 @@ static unsigned long shrink_page_list(st
goto keep_
close,
- .nopage = snd_usX2Y_hwdep_pcm_vm_nopage,
+ .fault = snd_usX2Y_hwdep_pcm_vm_fault,
};
Index: linux-2.6/Documentation/fb/deferred_io.txt
===
--- linux-2.6.orig/Documentation/fb/deferred_io.txt
+++ linux-2.6/Doc
On Sun, Nov 11, 2007 at 09:04:29PM -0500, Jeff Garzik wrote:
> Nick Piggin wrote:
> >Index: linux-2.6/sound/oss/via82cxxx_audio.c
> >===
> >--- linux-2.6.orig/sound/oss/via82cxxx_audio.c
> >+++ linux-2.6/
On Tuesday 13 November 2007 07:13, Matt Mackall wrote:
> On Fri, Nov 09, 2007 at 11:36:56PM +1100, Nick Piggin wrote:
> > Hi,
> >
> > Just ran some tbench numbers (from dbench-3.04), on a 2 socket, 8
> > core x86 system, with 1 NUMA node per socket. With kernel 2.6.24
On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
> On Sat, 10 Nov 2007, Nick Piggin wrote:
> > BTW. your size-2048 kmalloc cache is order-1 in the default setup,
> > wheras kmalloc(1024) or kmalloc(4096) will be order-0 allocations. And
> > SLAB also uses order-0 fo
On Wednesday 14 November 2007 06:22, David Brownell wrote:
> On Tuesday 13 November 2007, Ingo Molnar wrote:
> > * David Brownell <[EMAIL PROTECTED]> wrote:
> > > > > I speculate that either the design has changed (without fanfare),
> > > > > or else that stuff is in RT kernels and has not yet gone
On Tuesday 13 November 2007 01:30, [EMAIL PROTECTED] wrote:
> From: Martin Schwidefsky <[EMAIL PROTECTED]>
>
> In order to change the layout of the page tables after an mmap has
> crossed the adress space limit of the current page table layout a
> architecture hook in get_unmapped_area is needed. T
rant on :) ... These aren't directed specifically at Andrew, but
everyone who merges patches or is involved in the release process.
On Wednesday 14 November 2007 08:04, Andrew Morton wrote:
> On Tue, 13 Nov 2007 21:00:30 +0100 (CET) Christian Kujau
<[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Nov 20
On Wednesday 14 November 2007 12:58, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Tue, 13 Nov 2007 22:41:58 +1100
>
> > On Tuesday 13 November 2007 06:44, Christoph Lameter wrote:
> > > On Sat, 10 Nov 2007, Nick Piggin wrote:
> > >
On Wednesday 14 November 2007 10:04, Marc Donner wrote:
> hi
>
> i got this kernel bug on our production system, which is running since last
> saturday.
>
> anybody an idea??
Hugh might be of most help here, cc'ed.
But for the preliminary questions -- Is the bug reproduceable? And
if it is possib
On Wednesday 14 November 2007 17:12, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 04:36:24 +1100
>
> > On Wednesday 14 November 2007 12:58, David Miller wrote:
> > > I suspect the issue is about having a huge skb->data lin
On Wednesday 14 November 2007 17:52, David Brownell wrote:
> On Tuesday 13 November 2007, Andrew Morton wrote:
> > > I'll highlight the
> > > point that such bitops shouldn't be preemption points.
> >
> > Disagree. *everything* should be a preemption point.
>
> So it's wrong that uses the
> same
On Wednesday 14 November 2007 19:20, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > I mean, if you have a
> > timing critical operation, then you should ensure you have priorities
> > set correctly so that you simply don't get preempted.
&g
On Wednesday 14 November 2007 19:37, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > Upstream, all spinlocks prevent preemption.
>
> I chose my wording carefully though. A preemption point is
> more than just a small region where preemption isn'
On Wednesday 14 November 2007 17:37, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> > I'm doing some oprofile runs now to see if I can get any more info.
OK, in vanilla kernels, the page allocator definitely shows higher
in the results (than with Herbert'
On Wednesday 14 November 2007 09:27, Nick Piggin wrote:
> > 2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev->feastures
> >setting.
>
> Will try that now.
Doesn't help (with vanilla kernel -- Herbert's patch applied).
data_len histogram drops
On Wednesday 14 November 2007 22:10, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 09:27:39 +1100
>
> > OK, in vanilla kernels, the page allocator definitely shows higher
> > in the results (than with Herbert's patch reverted).
On Wednesday 14 November 2007 22:48, Herbert Xu wrote:
> On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote:
> > So the thing that's being effected here in TCP is
> > net/ipv4/tcp.c:select_size(), specifically the else branch:
>
> Thanks for the pointer. Indeed there is a bug in that are
On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> David Miller writes:
> > This is my impression too, all of the things being done with
> > a slew of system calls would be better served by real special
> > files and appropriate fops.
>
> Special files and fops really only work well if yo
On Wednesday 14 November 2007 22:58, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 10:49:48 +1100
>
> > On Wednesday 14 November 2007 22:44, Paul Mackerras wrote:
> > > David Miller writes:
> > > > This is my impress
On Wednesday 14 November 2007 23:07, David Miller wrote:
> From: Paul Mackerras <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 23:03:24 +1100
>
> > You're suggesting that the behaviour of a read() should depend on what
> > was in the buffer before the read? Gack! Surely you have better
> > taste th
t; + if ((size + addr) < addr)
> + goto out;
> + if (addr > end - size)
> + goto out;
>
> found:
> area->next = *p;
Yeah I noticed these missing checks when recently working in
this area as well. Weren't sure if I was missing something or
no
On Wed, Nov 14, 2007 at 09:01:39PM +0100, Peter Zijlstra wrote:
> Normal locking order is:
>
> i_mutex
> mmap_sem
>
> However NFS's ->mmap hook, which is called under mmap_sem, can take i_mutex.
> Avoid this potential deadlock by doing the work that requires i_mutex from
> the new ->mmap_pr
On Wed, Nov 14, 2007 at 05:18:50PM -0500, Trond Myklebust wrote:
>
> On Wed, 2007-11-14 at 22:50 +0100, Peter Zijlstra wrote:
> > Right, but I guess what Nick asked is, if pages could be stale to start
> > with, how is that avoided in the future.
> >
> > The way I understand it, this re-validate
On Thursday 15 November 2007 09:56, Chuck Ebbert wrote:
> On 11/14/2007 05:17 AM, Nick Piggin wrote:
> > But in general, for special files, I guess the response is usually
> > some structured data (that is not visible at the syscall layer).
> > So I don't see a big p
On Thursday 15 November 2007 08:30, Paul Mackerras wrote:
> Nick Piggin writes:
> > What I really mean is a readv-like syscall, but one that also
> > vectorises the file offset. Maybe this is useful enough as a generic
> > syscall that also helps Paul's example...
>
On Thursday 15 November 2007 10:46, David Miller wrote:
> From: Herbert Xu <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 19:48:44 +0800
> > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
>
> Applied and I'll queue it up for -stable too.
Good result. Thanks, everyone!
-
To unsubscribe from this list
On Thursday 15 November 2007 12:11, Herbert Xu wrote:
> On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote:
> > Well this is likely the result of the SLUB regression. If you allocate an
> > order 1 page then the zone locks need to be taken. SLAB queues the a
Yeah, it appears this is
On Thursday 15 November 2007 17:28, David Brownell wrote:
> On Tuesday 13 November 2007, Nick Piggin wrote:
> > > All this does is prevent constant and needless checking for
> > > "do you want to preempt me now?" "now?" "now?" in "
On Thursday 15 November 2007 06:19, Nick Piggin wrote:
> On Thursday 15 November 2007 19:17, David Brownell wrote:
> > On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > > All this does is prevent constant and needless checking for
> > > > > >
On Thursday 15 November 2007 19:17, David Brownell wrote:
> On Wednesday 14 November 2007, Nick Piggin wrote:
> > > > > All this does is prevent constant and needless checking for
> > > > > "do you want to preempt me now?" "now?" "now?
icular reason that you're using it?
Thanks,
Nick
Previously, it would be possible for prev->next to point to &free_slob_pages,
and thus we would try to move a list onto itself, and bad things would
happen.
It seems a bit hairy to be doing list operations with the list marker as an
On Thursday 15 November 2007 22:28, Ingo Molnar wrote:
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
> > Anyway, I'm really happy to see you're testing and using SLOB upstream
> >
> > :) Is there any particular reason that you're using it?
>
> i som
On Thursday 15 November 2007 23:48, Ingo Molnar wrote:
> > From: Nick Piggin <[EMAIL PROTECTED]>
> >
> > - if (free_slob_pages.next != prev->next)
> > + if (prev != free_slob_pages.prev &&
> > +
On Friday 26 October 2007 02:55, Randy Dunlap wrote:
> > Hmm, can we simply do
> >
> > static inline int test_and_set_bit_lock(int nr, volatile unsigned long *
> > addr) {
> > return test_and_set_bit(nr, addr);
> > }
> >
> > please ?
>
> Certainly. That does look better.
Thanks!
>
> ---
>
>
On Thu, Oct 25, 2007 at 09:07:36PM +0200, Jan Kara wrote:
> Hi,
>
> > This is overdue, sorry. Got a little complicated, and I've been away from
> > my filesystem test setup so I didn't want ot send it (lucky, coz I found
> > a bug after more substantial testing).
> >
> > Anyway, RFC?
> Hmm, m
On Thursday 25 October 2007 17:15, Andi Kleen wrote:
> On Thursday 25 October 2007 05:24, Nick Piggin wrote:
> > Basically, what the gcc developers are saying is that gcc is
> > free to load and store to any memory location, so long as it
> > behaves as if the instruct
Can you retain cc list, please?
On Friday 26 October 2007 07:42, David Schwartz wrote:
> I asked a collection of knowledgeable people I know about the issue. The
> consensus is that the optimization is not permitted in POSIX code but that
> it is permitted in pure C code. The basic argument
On Friday 26 October 2007 09:09, Andi Kleen wrote:
> On Friday 26 October 2007 00:49:42 Nick Piggin wrote:
> > Marking volatile I think is out of the question. To start with,
> > volatile creates really poor code (and most of the time we actually
> > do want the code in criti
On Friday 26 October 2007 09:55, Andi Kleen wrote:
> > But we don't actually know what it is, and it could change with
> > different architectures or versions of gcc. I think the sanest thing
> > is for gcc to help us out here, seeing as there is this very well
> > defined requirement that we want.
Hi,
Just out of interest, I did a grep for files containing test_and_set_bit
as well as clear_bit (excluding obvious ones like include/asm-*/bitops.h).
Quite a few interesting things. There is a lot of stuff in drivers/* that
could be suspect, WRT memory barriers, including lots I didn't touch. L
On Friday 26 October 2007 13:35, Benjamin Herrenschmidt wrote:
[acks]
Thanks for those...
> > Index: linux-2.6/include/asm-powerpc/mmu_context.h
> > ===
> > --- linux-2.6.orig/include/asm-powerpc/mmu_context.h
> > +++ linux-2.6/incl
On Saturday 27 October 2007 15:21, Mike Galbraith wrote:
> Greetings,
>
> For quite a while now, RT kernels have been locking up on me
> occasionally while my back is turned. Yesterday, the little bugger
> finally pounced while my serial console box was up and waiting.
>
> [10138.162953] WARNING:
> that is null, don't bother with the truncate check.
>
> Something like this
I think it's a fine minimal patch. Maybe add a comment to say exactly
what we're doing here (pagecache generally just uses !mapping to test
for truncate).
Otherwise, Acked-by: Nick Piggin <[EMAIL
ck for the
> ramdisk driver. This avoids try_to_free_buffers for ramdisk pages.
I think this is the least intrusive change that is least likely
to break rd, or any other kernel code, that we've seen. It really
should go in 2.6.24, IMO.
Acked-by: Nick Piggin <[EMAIL PROTECTED]>
On Sunday 28 October 2007 14:32, Christoph Lameter wrote:
> Too many troubles with the bitlocks and we really do not need
> to do any bitops. Bitops do not effectively retrieve the old
> value which we want. So use a cmpxchg instead on the arches
> that allow it.
>
> Instead of modifying the page->
On Wednesday 31 October 2007 05:32, Christoph Lameter wrote:
> On Tue, 30 Oct 2007, Nick Piggin wrote:
> > Is this actually a speedup on any architecture to roll your own locking
> > rather than using bit spinlock?
>
> It avoids one load from memory when allocating and
601 - 700 of 1974 matches
Mail list logo
