From: Vincent Legout <vincent@legout.info>
To: 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: Tue, 02 Sep 2014 10:16:44 -0400 [thread overview]
Message-ID: <87sika5cqb.fsf@cecht.legt.fr> (raw)
In-Reply-To: <CAE-h8tG6VCG0oX=AsPA-jKGqC=FheJD=4awByMukkUgD4uOUDg@mail.gmail.com> (Juri Lelli's message of "Tue, 2 Sep 2014 11:36:08 +0100")
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.
Thanks!
Vincent
next prev parent reply other threads:[~2014-09-02 14:16 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 [this message]
2014-09-03 10:00 ` Daniel Wagner
2014-09-03 13:06 ` Daniel Wagner
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=87sika5cqb.fsf@cecht.legt.fr \
--to=vincent@legout.info \
--cc=juri.lelli@arm.com \
--cc=juri.lelli@gmail.com \
--cc=kevinpb@vt.edu \
--cc=linux-rt-users@vger.kernel.org \
/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.