From: Daniel Wagner <wagi@monom.org>
To: Vincent Legout <vincent@legout.info>, Juri Lelli <juri.lelli@gmail.com>
Cc: Kevin Burns <kevinpb@vt.edu>,
linux-rt-users <linux-rt-users@vger.kernel.org>,
juri.lelli@arm.com
Subject: Re: set_schedattr + cpuset issue
Date: Wed, 03 Sep 2014 15:06:02 +0200 [thread overview]
Message-ID: <5407123A.6000908@monom.org> (raw)
In-Reply-To: <5406E6C0.1060606@monom.org>
On 09/03/2014 12:00 PM, Daniel Wagner wrote:
>
> On 09/02/2014 04:16 PM, Vincent Legout wrote:
>> Hi,
>>
>> Juri Lelli <juri.lelli@gmail.com> writes:
>>
>>> thanks a lot for your report. I was also actually experiencing something that I
>>> think is related to your issue, but then I didn't find any time to send out
>>> a proper patch :/.
>>>
>>> Could you please test what I've attached and see if it fixes your problem?
>>
>> Thanks for the patch, it fixes the second issue I mentioned in my
>> previous email, i.e. the one for which I posted a patch. For this issue,
>> FWIW:
>>
>> Tested-by: Vincent Legout <vincent@legout.info>
>> Tested-by: Kevin Burns <kevinpb@vt.edu>
>>
>> But it doesn't seem to fix the main issue related to cpusets and
>> SCHED_DEADLINE. It still fails if we don't come back to SCHED_OTHER
>> before moving the task to another cpuset. I think it's due to the fact
>> that SCHED_DEADLINE's data structures don't seem to be aware that a task
>> migrated, they are not updated during this process. Any idea where I
>> could have a look? Or if this is not supported, would it be possible to
>> add some checks such that total_bw doesn't overflow when calling
>> __dl_clear? If yes, I can try to provide a patch.
>
> I just saw this thread after sending a patch for this problem. It's not
> yet in the archive, though it is called:
>
> "[PATCH] sched: Reset bandwith on task when switching from
> SCHED_DEADLINE away"
>
> And obviously, I forgot to cc Juri. Sorry about that.
After fixing my sender address it even hit the archive:
https://lkml.org/lkml/2014/9/3/354
cheers,
daniel
prev parent reply other threads:[~2014-09-03 13:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAMLzMweCcxPBJExGsY-2oHK6sdF6EVgBsa1XVxQT0=kzNRZAJQ@mail.gmail.com>
2014-07-10 10:20 ` set_schedattr + cpuset issue Juri Lelli
2014-08-28 21:07 ` Vincent Legout
2014-09-02 10:36 ` Juri Lelli
2014-09-02 14:16 ` Vincent Legout
2014-09-03 10:00 ` Daniel Wagner
2014-09-03 13:06 ` Daniel Wagner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5407123A.6000908@monom.org \
--to=wagi@monom.org \
--cc=juri.lelli@arm.com \
--cc=juri.lelli@gmail.com \
--cc=kevinpb@vt.edu \
--cc=linux-rt-users@vger.kernel.org \
--cc=vincent@legout.info \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.