From: Hao Xu <firstname.lastname@example.org> To: "Michal Koutný" <email@example.com> Cc: Jens Axboe <firstname.lastname@example.org>, Zefan Li <email@example.com>, Tejun Heo <firstname.lastname@example.org>, Johannes Weiner <email@example.com>, Pavel Begunkov <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Joseph Qi <email@example.com> Subject: Re: [PATCH v4 0/2] refactor sqthread cpu binding logic Date: Fri, 3 Sep 2021 22:43:59 +0800 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20210902164808.GA10014@blackbody.suse.cz> 在 2021/9/3 上午12:48, Michal Koutný 写道: > Hello Hao. > > On Wed, Sep 01, 2021 at 08:43:20PM +0800, Hao Xu <email@example.com> wrote: >> This patchset is to enhance sqthread cpu binding logic, we didn't >> consider cgroup setting before. In container environment, theoretically >> sqthread is in its container's task group, it shouldn't occupy cpu out >> of its container. > > I see in the discussions that there's struggle to make > set_cpus_allowed_ptr() do what's intended under the given constraints. > > IIUC, set_cpus_allowed_ptr() is conventionally used for kernel threads > . But does the sqthread fall into this category? You want to have it > _directly_ associated with a container and its cgroups. It looks to me sqthread is in it's creator's task group, so it is like a userspace thread from this perspective. When it comes to container environemt sqthread naturely belongs to a container which also contains its creator And it has same cgroup setting with it's creator by default. > more like a userspace thread (from this perspective, not literally). Or > is there a different intention? > > It seems to me that reusing the sched_setaffinity() (with all its > checks and race pains/solutions) would be a more universal approach. > (I don't mean calling sched_setaffinity() directly, some parts would > need to be factored separately to this end.) WDYT? > > > Regards, > Michal > >  Not only spending their life in kernel but providing some > delocalized kernel service. >
prev parent reply other threads:[~2021-09-03 14:44 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-01 12:43 Hao Xu 2021-09-01 12:43 ` [PATCH 1/2] cpuset: add a helper to check if cpu in cpuset of current task Hao Xu 2021-09-01 12:43 ` [PATCH 2/2] io_uring: consider cgroup setting when binding sqpoll cpu Hao Xu 2021-09-01 16:41 ` Tejun Heo 2021-09-01 16:42 ` Tejun Heo 2021-09-03 15:04 ` Hao Xu 2021-09-07 16:54 ` Tejun Heo 2021-09-07 19:28 ` Hao Xu 2021-09-02 16:48 ` [PATCH v4 0/2] refactor sqthread cpu binding logic Michal Koutný 2021-09-02 18:00 ` Jens Axboe 2021-09-09 12:34 ` Michal Koutný 2021-09-03 14:43 ` Hao Xu [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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH v4 0/2] refactor sqthread cpu binding logic' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).