[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0608090050500.23474@frodo.shire>
Date: Thu, 10 Aug 2006 00:05:57 +0200 (CEST)
From: Esben Nielsen <nielsen.esben@...glemail.com>
To: Bill Huey <billh@...ppy.monkey.org>
cc: Steven Rostedt <rostedt@...dmis.org>,
Robert Crocombe <rcrocomb@...il.com>,
linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Darren Hart <dvhltc@...ibm.com>
Subject: Re: [Patch] restore the RCU callback to defer put_task_struct() Re:
Problems with 2.6.17-rt8
On Mon, 7 Aug 2006, Bill Huey wrote:
> On Mon, Aug 07, 2006 at 07:56:15PM -0700, Bill Huey wrote:
>> On Thu, Aug 03, 2006 at 10:27:41AM -0400, Steven Rostedt wrote:
>>
>> ...(output and commentary a log deleted)...
>>
>>> This could also have a side effect that messes things up.
>>>
>>> Unfortunately, right now I'm assigned to other tasks and I cant spend
>>> much more time on this at the moment. So hopefully, Ingo, Thomas or
>>> Bill, or someone else can help you find the reason for this problem.
>>
>> Steve and company,
>>
>> Speaking of which, after talking to Steve about this and confirming this
>> with a revert of changes. put_task_struct() can't deallocated memory from
>> either the zone or SLAB cache without taking a sleeping lock. It can't
>> be called directly from finish_task_switch to reap the thread because of
>> that (violation in atomic).
>>
>> It is for this reason the RCU call back to delay processing was put into
>> place to reap threads and was, seemingly by accident, missing from
>> patch-2.6.17-rt7 to -rt8. That is what broke it in the first place.
>>
>> I tested it with a "make -j4" which triggers the warning and it they all
>> go away now.
>>
>> Reverse patch attached:
>
> Resend with instrumentation code removed:
>
> bill
>
>
I had a long discussion with Paul McKenney about this. I opposed the patch
from a latency point of view: Suddenly a high-priority RT task could be
made into releasing a task_struct. It would be better for latencies to
defer it to a low priority task.
The conclusion we ended up with was that it is not a job for the RCU
system, but it ought to be deferred to some other low priority task to
free the task_struct.
Esben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists