On Fri, Mar 01, 2019 at 01:57:25PM -0800, Bart Van Assche wrote:
> Change "execuing" into "executing" and "guarnateed" into "guaranteed".
>
> Cc: Lai Jiangshan
> Signed-off-by: Bart Van Assche
Applied to wq/for-5.1.
Thanks.
--
tejun
_work_fn().
>
> Fixes: 682aa8e1a6a1 ("writeback: implement unlocked_inode_to_wb transaction
> and use it for stat updates")
> Signed-off-by: Greg Thelen
Acked-by: Tejun Heo
Thanks.
--
tejun
Hey, Oleg.
On Fri, Feb 22, 2019 at 05:34:42PM +0100, Oleg Nesterov wrote:
> > ptrace support is a lot less important than kill for sure but if at
> > all possible I think it'd be better to have it
>
> Tejun, I agree it would be better. I did not argue with that.
>
> The question is how this can
Hello, Oleg.
On Thu, Feb 21, 2019 at 05:29:24PM +0100, Oleg Nesterov wrote:
> But to me this is a reasonable trade-off because this way we do not add
> additional complexity to the kernel.
So, I really wanna avoid allowing userspace to cause D state sleeps.
It's not impossible to work around but
On Mon, Feb 18, 2019 at 03:28:11PM +0900, Masahiro Yamada wrote:
> This is a remnant of commit 5f155f27cb7f ("mm, cpuset: always use
> seqlock when changing task's nodemask").
>
> Signed-off-by: Masahiro Yamada
Applied to cgroup/for-5.0.
Thanks.
--
tejun
On Sat, Feb 16, 2019 at 08:56:04AM +0800, Yang Shi wrote:
> Since PSI has implemented some kind of measure of memory pressure, the
> statement about lack of such measure is not true anymore.
>
> Cc: Tejun Heo
> Cc: Johannes Weiner
> Cc: Jonathan Corbet
> Si
>From b4ff1b44bcd384d22fcbac6ebaf9cc0d33debe50 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 15 Feb 2019 11:01:31 -0800
cgroup_rstat_cpu_pop_updated() is used to traverse the updated cgroups
on flush. While it was only visiting updated ones in the subtree, it
was visiting @r
Hello,
On Fri, Feb 08, 2019 at 10:05:50AM +, Patrick Bellasi wrote:
> a) are available only for non-root nodes, both on default and legacy
>hierarchies, while system wide clamps are defined by a generic
>interface which does not depends on cgroups
>
> b) do not enforce any
On Sat, Feb 09, 2019 at 04:05:33PM +0100, Tibor Billes wrote:
> cgroup: add documentation for pids.events file
>
> Document the event counters file for pid cgroups.
>
> Signed-off-by: Tibor Billes
Applied to cgroup/for-5.0.
Thanks.
--
tejun
On Mon, Feb 04, 2019 at 05:09:50PM -0500, Sven Van Asbroeck wrote:
> In modules which extensively use devm_ resource management, it is often
> easy to overlook (delayed) work that is left pending or running after the
> module is unloaded. This could introduce user-after-free issues.
>
> Nudge
de/cgroup-v2.rst:1511: WARNING: Block quote ends
> without a blank line; unexpected unindent.
> Documentation/admin-guide/cgroup-v2.rst:1512: WARNING: Block quote ends
> without a blank line; unexpected unindent.
>
> Signed-off-by: Randy Dunlap
> Cc: Tejun Heo
> Cc: L
een done on ARM target.
>
> Signed-off-by: Ayush Mittal
> Signed-off-by: Vaneet Narang
Acked-by: Tejun Heo
Thanks.
--
tejun
On Wed, Feb 06, 2019 at 04:05:28PM +0100, Johannes Weiner wrote:
> This function can only be called safely from very specific scheduler
> contexts. Document those.
>
> Suggested-by: Andrew Morton
> Signed-off-by: Johannes Weiner
Acked-by: Tejun Heo
Thanks.
--
tejun
On Thu, Jan 31, 2019 at 03:22:19PM +0100, Andrea Parri wrote:
> Fix wildcard patterns and add cgroup-v2 documentation.
>
> Signed-off-by: Andrea Parri
Applied to cgroup/for-5.0.
Thanks.
--
tejun
On Mon, Jan 28, 2019 at 05:00:13PM +0100, Oleg Nesterov wrote:
> The only user of cgroup_subsys->free() callback is pids_cgrp_subsys which
> needs pids_free() to uncharge the pid.
>
> However, ->free() is called from __put_task_struct()->cgroup_free() and this
> is too late. Even the trivial
On Wed, Jan 30, 2019 at 06:41:17PM +0100, Michal Hocko wrote:
> But we are discussing the file name effectively. I do not see a long
> term maintenance burden. Confusing? Probably yes but that is were the
Cost on user side.
> documentation would be helpful.
which is an a lot worse option with
Hello, Michal.
On Wed, Jan 30, 2019 at 05:50:58PM +0100, Michal Hocko wrote:
> > Yeah, cgroup.events and .stat files as some of the local stats would
> > be useful too, so if we don't flip memory.events we'll end up with sth
> > like cgroup.events.local, memory.events.tree and memory.stats.local,
Hello,
On Tue, Jan 29, 2019 at 03:43:06PM +0100, Michal Hocko wrote:
> All memcg events are represented non-hierarchical AFAICS
> memcg_memory_event() simply accounts at the level when it happens. Or do
> I miss something? Or are you talking about .events files for other
> controllers?
Yeah,
.
Maybe it can describe better why this is safe in this use case and
not suitable as a generic interface but other than that,
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello, Andrew.
On Mon, Jan 28, 2019 at 02:03:36PM -0800, Andrew Morton wrote:
> > +#include "../workqueue_internal.h"
>
> "Only to be included by workqueue and core kernel subsystems"
>
> I'm not sure that psi qualifies. Perhaps wq_worker_last_func() should
> be declared in
Hello, Michal.
On Mon, Jan 28, 2019 at 06:05:26PM +0100, Michal Hocko wrote:
> Yeah, that is quite clear. But it also assumes that the hierarchy is
> pretty stable but cgroups might go away at any time. I am not saying
> that the aggregated events are not useful I am just saying that it is
>
Hello,
On Mon, Jan 28, 2019 at 08:08:26AM -0800, Shakeel Butt wrote:
> Do you envision a separate interface/file for recursive and local
> counters? That would make notifications simpler but that is an
> additional interface.
I need to think more about it but my first throught is that a separate
Hello, Shakeel.
On Mon, Jan 28, 2019 at 07:59:33AM -0800, Shakeel Butt wrote:
> Why not make this configurable at the delegation boundary? As you
> mentioned, there are jobs who want centralized workload manager to
> watch over their subtrees while there can be jobs which want to
> monitor their
Hello, Michal.
On Mon, Jan 28, 2019 at 04:18:59PM +0100, Michal Hocko wrote:
> How do you make an atomic snapshot of the hierarchy state? Or you do
> not need it because event counters are monotonic and you are willing to
> sacrifice some lost or misinterpreted events? For example, you receive
>
Hello,
On Mon, Jan 28, 2019 at 03:52:10PM +0100, Michal Hocko wrote:
> > All .events files generate aggregated stateful notifications. For
> > anyone to do anything, they'd have to remember the previous state to
> > identify what actually happened. Being hierarchical, it'd of course
> > need to
me), and it makes sense to bundle this with the file
> notifications.
...
> Signed-off-by: Chris Down
> Acked-by: Johannes Weiner
Acked-by: Tejun Heo
Michal has a valid counterpoint that this is a change in userland
visible behavior but to me this patch seems to be more of a bug fix
than a
Hello, Michal.
On Mon, Jan 28, 2019 at 01:51:51PM +0100, Michal Hocko wrote:
> > For example, a workload manager watching over a subtree for a job with
> > nested memory limits set by the job itself. It wants to take action
> > (reporting and possibly other remediative actions) when something
Hello, Michal.
On Fri, Jan 25, 2019 at 06:37:13PM +0100, Michal Hocko wrote:
> > What if a user wants to monitor any ooms in the subtree tho, which is
> > a valid use case?
>
> How is that information useful without know which memcg the oom applies
> to?
For example, a workload manager watching
Hello, Michal.
On Fri, Jan 25, 2019 at 09:42:13AM +0100, Michal Hocko wrote:
> > If you read my sentence again, I'm not talking about the kernel but
> > the surrounding infrastructure that consumes this data. The risk is
> > not dependent on the age of the interface age, but on its adoption.
>
>
On Fri, Jan 25, 2019 at 08:52:11AM +0100, Arkadiusz Miśkiewicz wrote:
> On 24/01/2019 12:21, Arkadiusz Miśkiewicz wrote:
> > On 17/01/2019 14:17, Arkadiusz Miśkiewicz wrote:
> >> On 17/01/2019 13:25, Aleksa Sarai wrote:
> >>> On 2019-01-17, Arkadiusz Miśkiewicz wrote:
> Using kernel 4.19.13.
On Wed, Jan 23, 2019 at 09:44:12AM +0900, Tetsuo Handa wrote:
> Daniel Jordan wrote:
> > On Sat, Jan 19, 2019 at 11:41:22AM +0900, Tetsuo Handa wrote:
> > > On 2019/01/19 4:48, Daniel Jordan wrote:
> > > > On Sat, Jan 19, 2019 at 02:04:58AM +0900, Tetsuo Handa wrote:
> > > > __queue_work has a
On Fri, Dec 21, 2018 at 04:03:00PM -0800, Roman Gushchin wrote:
> This patchset implements freezer for cgroup v2.
>
> It provides similar functionality as v1 freezer, but the interface
> conforms to the cgroup v2 interface design principles, and it
> provides a better user experience: tasks can
Hello, Michal.
On Thu, Jan 24, 2019 at 09:22:52AM +0100, Michal Hocko wrote:
> I do not think we can do that for two reasons. It breaks the existing
> semantic userspace might depend on and more importantly this is not a
> correct behavior IMO.
This is a valid concern but I'll come back to this
On Thu, Jan 17, 2019 at 09:47:34AM +0100, Juri Lelli wrote:
> Hi,
>
> v6 of a series of patches, originally authored by Mathieu, with the intent
> of fixing a long standing issue of SCHED_DEADLINE bandwidth accounting.
> As originally reported by Steve [1], when hotplug and/or (certain)
> cpuset
unwinding error path for regular registration and
> future net namespace change functionality for rdma device.
>
> Signed-off-by: Parav Pandit
> Signed-off-by: Leon Romanovsky
Acked-by: Tejun Heo
Thanks.
--
tejun
Hello, Linus.
On Sat, Jan 05, 2019 at 01:54:03PM -0800, Linus Torvalds wrote:
> And the first hit is 'fincore', which probably nobody cares about
> anyway, but it does
>
> fd = open (name, O_RDONLY)
> ..
> mmap(window, len, PROT_NONE, MAP_PRIVATE, ..
So, folks here have been using
Hello, Tetsuo.
On Fri, Jan 18, 2019 at 08:58:49PM +0900, Tetsuo Handa wrote:
> struct work_struct work;
> memset(, 0, sizeof(work));
> flush_work();
>
> . Is this behavior defined as "safe and no-op"? If this should be "safe and
> no-op",
Nope, that's a bug.
> we need to
Hello,
On Wed, Jan 02, 2019 at 07:05:38PM +0200, Mike Rapoport wrote:
> I agree that currently the bottom-up allocation after the kernel text has
> issues with KASLR. But this issues are not necessarily related to the
> memory hotplug. Even with a single memory node, a bottom-up allocation will
>
On Thu, Jan 03, 2019 at 01:49:55AM +0900, Tetsuo Handa wrote:
> kernfs_node_dentry() calls lookup_one_len_unlocked() which involves
> memory allocation, and memory allocation fault injection made
> lookup_one_len_unlocked() fail, and thus kernfs_node_dentry() failed.
> What's strange?
So,
Happy new year, Tetsuo.
On Wed, Jan 02, 2019 at 09:08:56PM +0900, Tetsuo Handa wrote:
> According to commit 633feee310de6b6c ("cgroup: refactor mount path and
> clearly distinguish v1 and v2 paths"), cgroup_do_mount() is failing to
> do full teardown steps for kernfs_mount()
Hello, Paolo.
On Sun, Dec 30, 2018 at 11:25:25AM +0100, Paolo Valente wrote:
> What's the benefit of throwing away months of work, on which we agreed
> before starting it, and that solves a problem already acknowledged by
> interested parties?
Showing multiple conflicting numbers definitely
On Sun, Dec 30, 2018 at 05:50:44PM +0100, Otto Sabart wrote:
> Improve readability using the :file: markup.
Heh, that's a minor plus for formatted output and minor minus for the
source. If this is a convention generally followed for
documentations, I have no objects. That said, can you please
On Sun, Dec 30, 2018 at 08:01:55PM +0100, Otto Sabart wrote:
> This patch fixes multiple build warnings:
> "WARNING: Block quote ends without a blank line; unexpected unindent."
>
> Signed-off-by: Otto Sabart
Applied to cgroup/for-4.22.
Thanks.
--
tejun
On Sun, Dec 30, 2018 at 10:40:29AM -0700, Jonathan Corbet wrote:
> On Sun, 30 Dec 2018 17:49:45 +0100
> Otto Sabart wrote:
>
> > The graphviz looks better. This patch also fixes multiple build warnings:
> > "WARNING: Block quote ends without a blank line; unexpected unindent."
> >
> >
to 3fc9c12d27b4ded4f1f761a800558dab2e6bbac5:
cgroup: Add named hierarchy disabling to cgroup_no_v1 boot param (2018-12-28
10:34:12 -0800)
Ondrej Mosnacek (1):
cgroup: fix parsing empty mount option string
Tejun Heo (5):
cpuset: Minor cgroup2 interface
On Fri, Dec 28, 2018 at 06:25:37PM +0100, Vincent Guittot wrote:
> > done without extra space as long as each node has the parent pointer,
> > which they do. Is the dedicated list an optimization?
>
> It prevents to parse and walk all task group struct every time.
> Instead, you just have to
Hello,
On Fri, Dec 28, 2018 at 10:30:07AM +0100, Vincent Guittot wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index d1907506318a..88b9118b5191 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -7698,7 +7698,8 @@ static void
for-4.21
for you to fetch changes up to 4d71c6f8771a6bccb844244f09831fa4624b22c1:
Merge branch 'for-4.20-fixes' into for-4.21 (2018-12-27 18:05:30 -0800)
Tejun Heo (4):
cpuset: Minor cgroup2 interface updates
cgroup: Add
On Thu, Dec 27, 2018 at 05:53:52PM -0800, Tejun Heo wrote:
> Vincent knows that part way better than me but I think the safest way
> would be doing the optimization removal iff tmp_alone_branch is
> already pointing to leaf_cfs_rq_list. IIUC, it's pointing to
> something else only wh
Hello,
On Thu, Dec 27, 2018 at 05:36:47PM -0800, Linus Torvalds wrote:
> > Unless I'm totally confused, which is definitely possible, I don't
> > think there's a race condition and the only bug is the
> > tmp_alone_branch pointer getting dangled, which maybe doesn't happen
> > all that much?
>
>
Happy holidays, everyone.
(cc'ing Rik, who has been looking at the scheduler code a lot lately)
On Thu, Dec 27, 2018 at 10:15:17AM -0800, Linus Torvalds wrote:
> [ goes off and looks ]
>
> Oh. unthrottle_cfs_rq -> enqueue_entity -> list_add_leaf_cfs_rq()
> doesn't actually seem to hold the rq
Hello, Paolo.
On Sun, Dec 23, 2018 at 12:00:14PM +0100, Paolo Valente wrote:
> 4.21 is coming ... and the legacy proportional share interface will
> be gone with cfq. This will break legacy code using the
> proportional-share interface on top of bfq. This code may just fail
> when trying to
oning it were not updated.
>
> Update comments to reflect current implementation.
>
> Signed-off-by: Juri Lelli
Acked-by: Tejun Heo
Prolly better to route through scheduler tree together with the second
patch?
Thanks.
--
tejun
Hello, Paolo.
On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote:
> If Tejun cannot see any solution to his concern, then can we just
> switch to this extension, considering that
> - for non-shared names the interface is *identical* to the current
> one;
> - by using this new
time it proved
> difficult to bisect, but we are continuing to get complaints about
> it as it renders the Debian Alpha installer somewhat useless, so I
> returned to trying to find the problem and managed to bisect it to:
>
> commit b38d08f3181c5025a7ce84646494cc4748492a3b
> Au
On Sat, Dec 01, 2018 at 03:12:56AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> kernel/cgroup/cpuset.c: In function 'cpuset_cancel_attach':
> kernel/cgroup/cpuset.c:2167:17: warning:
> variable 'cs' set but not used [-Wunused-but-set-variable]
>
> It never used
On Sat, Dec 01, 2018 at 03:12:56AM +, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> kernel/cgroup/cpuset.c: In function 'cpuset_cancel_attach':
> kernel/cgroup/cpuset.c:2167:17: warning:
> variable 'cs' set but not used [-Wunused-but-set-variable]
>
> It never used
Hello,
On Fri, Nov 30, 2018 at 04:13:07PM -0800, Daniel Jordan wrote:
> On Fri, Nov 30, 2018 at 11:18:19AM -0800, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, Nov 05, 2018 at 11:55:45AM -0500, Daniel Jordan wrote:
> > > Michal, you mentioned that kt
Hello,
On Fri, Nov 30, 2018 at 04:13:07PM -0800, Daniel Jordan wrote:
> On Fri, Nov 30, 2018 at 11:18:19AM -0800, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, Nov 05, 2018 at 11:55:45AM -0500, Daniel Jordan wrote:
> > > Michal, you mentioned that kt
Hello,
On Mon, Nov 05, 2018 at 11:55:45AM -0500, Daniel Jordan wrote:
> Michal, you mentioned that ktask should be sensitive to CPU utilization[1].
> ktask threads now run at the lowest priority on the system to avoid disturbing
> busy CPUs (more details in patches 4 and 5). Does this address
Hello,
On Mon, Nov 05, 2018 at 11:55:45AM -0500, Daniel Jordan wrote:
> Michal, you mentioned that ktask should be sensitive to CPU utilization[1].
> ktask threads now run at the lowest priority on the system to avoid disturbing
> busy CPUs (more details in patches 4 and 5). Does this address
On Mon, Nov 26, 2018 at 09:37:10AM -0500, Yangtao Li wrote:
> we include workqueue.h twice.It's unnecessary,so
> just remove them.
>
> Signed-off-by: Yangtao Li
Acked-by: Tejun Heo
Ditto. Please route through the trivial tree.
Thanks.
--
tejun
On Mon, Nov 26, 2018 at 09:37:10AM -0500, Yangtao Li wrote:
> we include workqueue.h twice.It's unnecessary,so
> just remove them.
>
> Signed-off-by: Yangtao Li
Acked-by: Tejun Heo
Ditto. Please route through the trivial tree.
Thanks.
--
tejun
On Mon, Nov 26, 2018 at 09:33:26AM -0500, Yangtao Li wrote:
> workqueue.h and kthread.h are included twice.It's unnecessary.
> hence just remove them.
>
> Signed-off-by: Yangtao Li
Acked-by: Tejun Heo
Can you route this through the trivial tree?
Thanks.
--
tejun
On Mon, Nov 26, 2018 at 09:33:26AM -0500, Yangtao Li wrote:
> workqueue.h and kthread.h are included twice.It's unnecessary.
> hence just remove them.
>
> Signed-off-by: Yangtao Li
Acked-by: Tejun Heo
Can you route this through the trivial tree?
Thanks.
--
tejun
On Tue, Nov 27, 2018 at 02:53:57PM +0800, Peng Wang wrote:
> "cgrp_ancestor_id_storage" is not used, so let's clean it up.
It is being used.
Thanks.
--
tejun
On Tue, Nov 27, 2018 at 02:53:57PM +0800, Peng Wang wrote:
> "cgrp_ancestor_id_storage" is not used, so let's clean it up.
It is being used.
Thanks.
--
tejun
Hello,
On Tue, Nov 20, 2018 at 05:39:03PM +, Roman Gushchin wrote:
> Yeah, it's a good point. I've thought about it mostly in the fork() context,
> where if freezing of a cgroup races with fork(), it makes no sense to
> switch the cgroup state back and forth. But that case is different, as
>
Hello,
On Tue, Nov 20, 2018 at 05:39:03PM +, Roman Gushchin wrote:
> Yeah, it's a good point. I've thought about it mostly in the fork() context,
> where if freezing of a cgroup races with fork(), it makes no sense to
> switch the cgroup state back and forth. But that case is different, as
>
Hello,
On Tue, Nov 20, 2018 at 04:43:52PM +, Roman Gushchin wrote:
> > But that wouldn't udpate the cgroup's frozen state and generate
> > notifications, right?
>
> Why? The task will be eventually trapped into cgroup_enter_frozen(),
> and from there cgroup_update_frozen() will be called.
Hello,
On Tue, Nov 20, 2018 at 04:43:52PM +, Roman Gushchin wrote:
> > But that wouldn't udpate the cgroup's frozen state and generate
> > notifications, right?
>
> Why? The task will be eventually trapped into cgroup_enter_frozen(),
> and from there cgroup_update_frozen() will be called.
On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > that also trigger frozen state update?
>
> It does! Just below these lines:
>
> /*
>* If the task isn't in the desired state, force it to it.
On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > that also trigger frozen state update?
>
> It does! Just below these lines:
>
> /*
>* If the task isn't in the desired state, force it to it.
On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> So instead of flush_work_at_nice, how about this?:
>
> void renice_work_sync(work_struct *work, long nice);
Wouldn't renice_or_cancel make more sense?
Thanks.
--
tejun
On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> So instead of flush_work_at_nice, how about this?:
>
> void renice_work_sync(work_struct *work, long nice);
Wouldn't renice_or_cancel make more sense?
Thanks.
--
tejun
Hello, Paolo.
On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote:
> - if all entities produce the same output, the this common output is
> shown only once;
> - if the outputs differ, then every per-entity output is shown,
> followed by the name of the entity that produced that
Hello, Paolo.
On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote:
> - if all entities produce the same output, the this common output is
> shown only once;
> - if the outputs differ, then every per-entity output is shown,
> followed by the name of the entity that produced that
On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> +void cgroup_freezer_migrate_task(struct task_struct *task,
> + struct cgroup *src, struct cgroup *dst)
> +{
> + lockdep_assert_held(_set_lock);
> +
> + /*
> + * Kernel threads are not
On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> +void cgroup_freezer_migrate_task(struct task_struct *task,
> + struct cgroup *src, struct cgroup *dst)
> +{
> + lockdep_assert_held(_set_lock);
> +
> + /*
> + * Kernel threads are not
On Fri, Nov 16, 2018 at 04:38:26PM -0800, Roman Gushchin wrote:
> Now the number of descendant cgroups and the number of dying
> descendant cgroups are synchronized using the cgroup_mutex.
>
> The number of descendant cgroups will be required by the cgroup v2
> freezer, which will use it to
On Fri, Nov 16, 2018 at 04:38:26PM -0800, Roman Gushchin wrote:
> Now the number of descendant cgroups and the number of dying
> descendant cgroups are synchronized using the cgroup_mutex.
>
> The number of descendant cgroups will be required by the cgroup v2
> freezer, which will use it to
> wake as quickly as possible), it's better to do it from kernfs_notify()
> directly. One example is calling sysfs_notify_dirent() from a hardware
> interrupt handler to wake up a thread and handle the interrupt in user
> space.
>
> Signed-off-by: Radu Rendec
Acked-by: Tejun He
> wake as quickly as possible), it's better to do it from kernfs_notify()
> directly. One example is calling sysfs_notify_dirent() from a hardware
> interrupt handler to wake up a thread and handle the interrupt in user
> space.
>
> Signed-off-by: Radu Rendec
Acked-by: Tejun He
On Thu, Nov 08, 2018 at 12:15:15PM -0800, Tejun Heo wrote:
> CSS_TASK_ITER_PROCS implements process-only iteration by making
> css_task_iter_advance() skip tasks which aren't threadgroup leaders;
> however, when an iteration is started css_task_iter_start() calls the
> inner hel
On Thu, Nov 08, 2018 at 12:15:15PM -0800, Tejun Heo wrote:
> CSS_TASK_ITER_PROCS implements process-only iteration by making
> css_task_iter_advance() skip tasks which aren't threadgroup leaders;
> however, when an iteration is started css_task_iter_start() calls the
> inner hel
Hello, Peter.
On Tue, Nov 20, 2018 at 01:46:24PM +0100, Peter Zijlstra wrote:
> Why though? The Changelog doesn't give rationale for the actual changes.
Ah yeah, sorry about that.
> And I'm not sure I agree with either one of them.
>
> The partition is a scheduling feature;
So is everything
Hello, Peter.
On Tue, Nov 20, 2018 at 01:46:24PM +0100, Peter Zijlstra wrote:
> Why though? The Changelog doesn't give rationale for the actual changes.
Ah yeah, sorry about that.
> And I'm not sure I agree with either one of them.
>
> The partition is a scheduling feature;
So is everything
On Tue, Nov 13, 2018 at 08:55:11PM +, Roman Gushchin wrote:
> > > > > + if (lock_task_sighand(task, )) {
> > > > > + if (test_bit(CGRP_FREEZE, >flags))
> > > > > + task->jobctl |= JOBCTL_TRAP_FREEZE;
> > > > > + else
> > > > > +
On Tue, Nov 13, 2018 at 08:55:11PM +, Roman Gushchin wrote:
> > > > > + if (lock_task_sighand(task, )) {
> > > > > + if (test_bit(CGRP_FREEZE, >flags))
> > > > > + task->jobctl |= JOBCTL_TRAP_FREEZE;
> > > > > + else
> > > > > +
>From c1bbd933e5fae83f96acd3f748bb01a0300b315d Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:06:41 -0800
Clearly mark the debug files and hide them by default by prefixing
".__DEBUG__.".
Signed-off-by: Tejun Heo
Cc: Peter Zijlstra (Intel)
Cc: Waiman Long
>From c1bbd933e5fae83f96acd3f748bb01a0300b315d Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:06:41 -0800
Clearly mark the debug files and hide them by default by prefixing
".__DEBUG__.".
Signed-off-by: Tejun Heo
Cc: Peter Zijlstra (Intel)
Cc: Waiman Long
>From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:03:33 -0800
* Rename the partition file from "cpuset.sched.partition" to
"cpuset.cpus.partition".
* When writing to the partition file, drop "0"
>From b1e3aeb11c5e86ee0988a038c4e7682d6beaa977 Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Tue, 13 Nov 2018 12:03:33 -0800
* Rename the partition file from "cpuset.sched.partition" to
"cpuset.cpus.partition".
* When writing to the partition file, drop "0"
Hello, Roman.
On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > + /* Should the cgroup and its descendants be frozen. */
> > > + bool freeze;
> >
> > Why not have this in freezer too?
>
> I thought that this variable is just the state of the cgroup.freeze knob,
> where the
Hello, Roman.
On Tue, Nov 13, 2018 at 06:47:55PM +, Roman Gushchin wrote:
> > > + /* Should the cgroup and its descendants be frozen. */
> > > + bool freeze;
> >
> > Why not have this in freezer too?
>
> I thought that this variable is just the state of the cgroup.freeze knob,
> where the
Hello, Daniel.
On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr,
> - bool from_cancel)
> + struct nice_work *nice_work, int flags)
> {
>
Hello, Daniel.
On Mon, Nov 05, 2018 at 11:55:50AM -0500, Daniel Jordan wrote:
> static bool start_flush_work(struct work_struct *work, struct wq_barrier
> *barr,
> - bool from_cancel)
> + struct nice_work *nice_work, int flags)
> {
>
even though it is but a comment.
>
> Signed-off-by: Paul E. McKenney
> Cc: Tejun Heo
> Cc: Jens Axboe
> Cc: Dennis Zhou
> Cc: Johannes Weiner
> Cc: "Dennis Zhou (Facebook)"
Acked-by: Tejun Heo
Thanks.
--
tejun
even though it is but a comment.
>
> Signed-off-by: Paul E. McKenney
> Cc: Tejun Heo
> Cc: Jens Axboe
> Cc: Dennis Zhou
> Cc: Johannes Weiner
> Cc: "Dennis Zhou (Facebook)"
Acked-by: Tejun Heo
Thanks.
--
tejun
even though it is but a comment.
>
> Signed-off-by: Paul E. McKenney
> Cc: Dennis Zhou
> Cc: Tejun Heo
> Cc: Christoph Lameter
Acked-by: Tejun Heo
Thanks.
--
tejun
401 - 500 of 22291 matches
Mail list logo
