On Thursday 05 March 2009 21:05:16 Jan Kara wrote:
> On Thu 05-03-09 13:55:43, Nick Piggin wrote:
> > On Thursday 05 March 2009 04:50:31 Jan Kara wrote:
> > > On Wed 04-03-09 16:55:35, Jan Kara wrote:
> > > > On Wed 04-03-09 15:51:09, Jan Kara wrote:
> > >
On Thursday 05 March 2009 04:50:31 Jan Kara wrote:
> On Wed 04-03-09 16:55:35, Jan Kara wrote:
> > On Wed 04-03-09 15:51:09, Jan Kara wrote:
> > > first, I'd like to point out that this has happened under UML so it
> > > can be just some obscure bug in that architecture but I belive it's
> > > wo
Jeff Dike wrote:
> The libc free wrapper wasn't correctly detecting buffers obtained with
> malloc(). This is now done by seeing if the page was reserved. This is
> the case for memory which is left aside for libc and isn't given to
> the page allocator. If we free a pointer in a reserved page,
Russell King wrote:
On Fri, Aug 12, 2005 at 08:21:45PM +0200, [EMAIL PROTECTED] wrote:
@@ -632,10 +632,11 @@ static inline int page_mapped(struct pag
* Used to decide whether a process gets delivered SIGBUS or
* just gets major/minor fault counters bumped up.
*/
-#define VM_FAULT_OOM (-1)
Srivatsa Vaddagiri wrote:
On Sun, May 08, 2005 at 02:14:23PM +1000, Nick Piggin wrote:
Yeah probably something around that order of magnitude. I suspect
there will fast be a point where either you'll get other timers
going off more frequently, and / or you simply get very quickly
dimini
Rusty Russell wrote:
On Sat, 2005-05-07 at 23:57 +0530, Srivatsa Vaddagiri wrote:
Two solutions have been proposed so far:
A. As per Nick's suggestion, impose a max limit (say some 100 ms or
say a second, Nick?) on how long a idle CPU can avoid taking
Yeah probably something arou
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
Nick Piggin wrote:
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules of
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
When a task is put to sleep, it is dequeued from the runqueue
while it is still running. The problem is that the runqueue
lock can be dropped and retaken in schedule() before the task
actually schedules off, and wait_task_inacti
Nick Piggin wrote:
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
I think th
Nick Piggin wrote:
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, IMO this is another bug to hold 2.6.11 for.
Sure. I wouldn't consider Bodo's patch to be the one to use though..
No. Something similar could be done that works on all architectures
and all wa
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait
Bodo Stroesser wrote:
Nick Piggin wrote:
Bodo Stroesser wrote:
I don't see how this could help because AFAIKS, child->saving is only
set and cleared while the runqueue is locked. And the same runqueue lock
is taken by wait_task_inactive.
Sorry, that not right. There are some routines c
Bodo Stroesser wrote:
Working with the new UML skas0 mode on my Xeon HT host, sporadically I saw
some processes on UML segfaulting.
In all cases, I could track this down to be caused by a gs segment
register,
that had the wrong contents.
This again is caused by a problem in the host linux: A ptra
14 matches
Mail list logo
