On Thu, Apr 30, 2015 at 11:32 AM, Steven Rostedt wrote:
> On Thu, 30 Apr 2015 20:07:21 +0200
> Peter Zijlstra wrote:
>> The irony, this is distinctly non deterministic code you're putting
>> under a RT specific preempt_disable ;-)
>
> I know :-(
>
> Unfortunately, a RT behaving fix would be much
ping?
On Wed, Feb 18, 2015 at 4:23 PM, wrote:
> From: Brian Silverman
>
> When non-realtime tasks get priority-inheritance boosted to a realtime
> scheduling class, RLIMIT_RTTIME starts to apply to them. However, the
> counter used for checking this (the same one used for SCHED_RR
> timeslices)
On Sat, Jul 5, 2014 at 1:26 PM, Thomas Gleixner wrote:
> On Mon, 30 Jun 2014, Austin Schuh wrote:
>> I think I might have an answer for my own question, but I would
>> appreciate someone else to double check. If list_empty erroneously
>> returns that there is work to do whe
On Tue, Jul 1, 2014 at 12:32 PM, Austin Schuh wrote:
> On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh wrote:
>> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>>> Completely untested patch below.
I've tested it and looked it over now, and feel pretty confiden
On Mon, Jun 30, 2014 at 8:01 PM, Austin Schuh wrote:
> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>> Completely untested patch below.
>
> By chance, I found this in my boot logs. I'll do some more startup
> testing tomorrow.
>
> Jun 30 19:54:
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
> Completely untested patch below.
By chance, I found this in my boot logs. I'll do some more startup
testing tomorrow.
Jun 30 19:54:40 vpc5 kernel: [0.670955] [ cut here ]
Jun 30 19:54:40 vpc5 kernel: [0.67
On Mon, Jun 30, 2014 at 5:12 PM, Austin Schuh wrote:
> On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
>> On Thu, 26 Jun 2014, Austin Schuh wrote:
>>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>>> out of __schedule to sched_
On Fri, Jun 27, 2014 at 7:24 AM, Thomas Gleixner wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> If I'm reading the rt patch correctly, wq_worker_sleeping was moved
>> out of __schedule to sched_submit_work. It looks like that changes
>> the conditions under w
On Fri, Jun 27, 2014 at 8:32 PM, Mike Galbraith
wrote:
> On Fri, 2014-06-27 at 18:18 -0700, Austin Schuh wrote:
>
>> It would be more context switches, but I wonder if we could kick the
>> workqueue logic completely out of the scheduler into a thread. Have
>> the schedule
On Fri, Jun 27, 2014 at 11:19 AM, Steven Rostedt wrote:
> On Fri, 27 Jun 2014 20:07:54 +0200
> Mike Galbraith wrote:
>
>> > Why do we need the wakeup? the owner of the lock should wake it up
>> > shouldn't it?
>>
>> True, but that can take ages.
>
> Can it? If the workqueue is of some higher prio
On Thu, Jun 26, 2014 at 3:35 PM, Thomas Gleixner wrote:
> On Thu, 26 Jun 2014, Austin Schuh wrote:
>> On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
>> wrote:
>> > CC'ing RT folks
>> >
>> > On Wed, May 21, 2014 at 8:23 AM, Austin Schuh
&g
On Wed, May 21, 2014 at 12:33 AM, Richard Weinberger
wrote:
> CC'ing RT folks
>
> On Wed, May 21, 2014 at 8:23 AM, Austin Schuh wrote:
>> On Tue, May 13, 2014 at 7:29 PM, Austin Schuh
>> wrote:
>>> Hi,
>>>
>>> I am observing a filesyst
On Wed, Jun 25, 2014 at 7:00 AM, Tejun Heo wrote:
>
> Hello,
>
> On Tue, Jun 24, 2014 at 08:05:07PM -0700, Austin Schuh wrote:
> > > I can see no reason why manual completion would behave differently
> > > from flush_work() in this case.
> >
> > I went lo
[Adding tglx to the cc. Sorry for any double sends]
On Mon, Jun 23, 2014 at 8:25 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jun 24, 2014 at 01:02:40PM +1000, Dave Chinner wrote:
>> start_flush_work() is effectively a special queue_work()
>> implementation, so if if it's not safe to call complete(
On Wed, May 21, 2014 at 12:30 PM, John Blackwood
wrote:
>> Date: Wed, 21 May 2014 03:33:49 -0400
>> From: Richard Weinberger
>> To: Austin Schuh
>> CC: LKML , xfs , rt-users
>>
>> Subject: Re: Filesystem lockup with CONFIG_PREEMPT_RT
>
>>
>
On Tue, May 13, 2014 at 7:29 PM, Austin Schuh wrote:
> Hi,
>
> I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
> patched kernel. I have currently only triggered it using dpkg. Dave
> Chinner on the XFS mailing list suggested that it was a rt-kernel
>
Hi,
I am observing a filesystem lockup with XFS on a CONFIG_PREEMPT_RT
patched kernel. I have currently only triggered it using dpkg. Dave
Chinner on the XFS mailing list suggested that it was a rt-kernel
workqueue issue as opposed to a XFS problem after looking at the
kernel messages.
$ uname
On Mon, Apr 7, 2014 at 1:08 PM, Austin Schuh wrote:
> On Mon, Apr 7, 2014 at 1:07 PM, Thomas Gleixner wrote:
>> On Mon, 7 Apr 2014, Austin Schuh wrote:
>>> You originally sent the patch out. I could send your patch out back
>>> to you, but that feels a bit weird ;)
&g
On Mon, Apr 7, 2014 at 1:07 PM, Thomas Gleixner wrote:
> On Mon, 7 Apr 2014, Austin Schuh wrote:
>> You originally sent the patch out. I could send your patch out back
>> to you, but that feels a bit weird ;)
>
> Wheee. Let me dig in my archives
https://lkml.org/lkml
On Mon, Apr 7, 2014 at 11:41 AM, Thomas Gleixner wrote:
> On Mon, 7 Apr 2014, Austin Schuh wrote:
>
>> Hi Thomas,
>>
>> Did anything come of this patch? Both Oliver and I have found that it
>> fixes real problems. I have multiple machines which have been running
&g
for two
> weeks now without problems.
>
> If you want me to test an improved version (as Austin suggested below) please
> send a patch.
>
> Best regards,
> Oliver
>
> On 23.12.2013 20:25, Austin Schuh wrote:
>> Hi Thomas,
>>
>> Did anything happen with
21 matches
Mail list logo
