Hello,
This email is to restart the discussion around the thread granularity
support for cgroup cpu controller, which got lost around the following
message.
http://thread.gmane.org/gmane.linux.kernel/2021959/focus=14454
While the previous discussion didn't reach a conclusion, it uncovered
the
On Fri, Jan 01, 2016 at 11:14:14AM -0800, Dan Williams wrote:
> On Fri, Jan 1, 2016 at 10:06 AM, Serge E. Hallyn
> wrote:
> > On Fri, Jan 01, 2016 at 01:42:57AM -0800, Dan Williams wrote:
> >> Commit 54b39d263704 "cgroup: cgroup namespace setns support" not
> >> booting is a separate issue.
> >
>
Hello,
> From fc54592077533ff2ff90ed54b72bf03b4378ca9f Mon Sep 17 00:00:00 2001
> From: Serge Hallyn
> Date: Thu, 31 Dec 2015 16:55:19 -0800
> Subject: [PATCH 1/1] cgroup_release_agent: grab css_set_lock around
> cgroup_path()
>
> Reported-by: Sergey Senozhatsky
> Signed-off-by: Serge Hallyn
d to better fit the documentation.
Signed-off-by: Aditya Kali
Signed-off-by: Serge Hallyn
Signed-off-by: Tejun Heo
---
Documentation/cgroup.txt | 147 +++
1 file changed, 147 insertions(+)
diff --git a/Documentation/cgroup.txt b/Documentation/cgrou
Hello,
I did some heavy editing of the documentation. How does this look?
Did I miss anything?
Thanks.
---
Documentation/cgroup.txt | 146 +++
1 file changed, 146 insertions(+)
--- a/Documentation/cgroup.txt
+++ b/Documentation/cgroup.txt
@@ -47,6 +
Applied 1-6 and 8 to cgroup/for-4.5.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Dec 22, 2015 at 10:23:26PM -0600, serge.hal...@ubuntu.com wrote:
> From: Aditya Kali
>
> Add a new kernfs api is added to lookup the dentry for a particular
> kernfs path.
>
> Signed-off-by: Aditya Kali
> Signed-off-by: Serge E. Hallyn
Greg, this is the other kernfs change in the seri
On Tue, Dec 22, 2015 at 10:23:22PM -0600, serge.hal...@ubuntu.com wrote:
> From: Aditya Kali
>
> The new function kernfs_path_from_node() generates and returns kernfs
> path of a given kernfs_node relative to a given parent kernfs_node.
>
> Signed-off-by: Aditya Kali
> Signed-off-by: Serge E. H
Hello,
On Tue, Dec 22, 2015 at 10:23:24PM -0600, serge.hal...@ubuntu.com wrote:
...
> +char *cgroup_path(struct cgroup *cgrp, char *buf, size_t buflen)
> +{
> + int ret;
> +
> + ret = cgroup_path_ns(cgrp, buf, buflen, current->nsproxy->cgroup_ns);
> + if (ret < 0 || ret >= buflen)
Hello, Serge.
On Tue, Dec 22, 2015 at 10:23:22PM -0600, serge.hal...@ubuntu.com wrote:
> @@ -164,18 +286,39 @@ void pr_cont_kernfs_name(struct kernfs_node *kn)
> void pr_cont_kernfs_path(struct kernfs_node *kn)
> {
> unsigned long flags;
> - char *p;
> + char *p = NULL;
> + int
Hello,
On Wed, Dec 16, 2015 at 08:47:35AM +0100, Richard Weinberger wrote:
> > Andrew? Are you or anyone else interested in picking up this patchset?
>
> I know I'm repeating myself. But this should be done in userspace.
Nothing in this posting explains why this is being added. Kinda
difficult
Hey,
On Wed, Dec 09, 2015 at 10:13:27PM +, Serge Hallyn wrote:
> we can rename kn_root to from here if you think that's clearer (and
> change the order here as well).
I think it'd be better for them to be consistent and in the same order
- the target and then the optional base.
> > Was conve
Hello, Serge.
On Wed, Dec 09, 2015 at 01:28:54PM -0600, serge.hal...@ubuntu.com wrote:
> +/* kernfs_node_depth - compute depth from @from to @to */
> +static size_t kernfs_depth(struct kernfs_node *from, struct kernfs_node *to)
...
> +char *kernfs_path(struct kernfs_node *kn, char *buf, size_t buf
Hello, Serge.
On Tue, Dec 08, 2015 at 05:21:24PM -0600, Serge E. Hallyn wrote:
> > Heh, is kernfs_obtain_root() the right name? Maybe
> > kernfs_node_to_inode()?
>
> kernfs_node_to_dentry?
>
> This would presumably make the question of whether to pass in a namespace
> moot?
Sounds good.
Thank
Hello, Serge.
On Tue, Dec 08, 2015 at 01:34:31PM -0600, Serge E. Hallyn wrote:
> > I'd prefer collecting all ns related declarations in a single place.
>
> I can group some of them, but free_cgroup_ns needs the
> cgroup_namespace definition, put_cgroup_ns() needs free_cgroup_ns(),
> and free_cgro
On Mon, Dec 07, 2015 at 05:06:21PM -0600, serge.hal...@ubuntu.com wrote:
> From: Aditya Kali
>
> Signed-off-by: Aditya Kali
> Signed-off-by: Serge Hallyn
> ---
> Documentation/cgroups/namespace.txt | 142
> +++
Please integrate the documentation into Documenta
Hello,
On Mon, Dec 07, 2015 at 05:06:20PM -0600, serge.hal...@ubuntu.com wrote:
> fs/kernfs/mount.c | 74
>
> include/linux/kernfs.h |2 ++
> kernel/cgroup.c| 39 -
> 3 files changed, 114 insertions(+),
On Mon, Dec 07, 2015 at 05:06:18PM -0600, serge.hal...@ubuntu.com wrote:
> static const char *proc_ns_follow_link(struct dentry *dentry, void **cookie)
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 2b3e2314..906f240 100644
> --- a/include/linux/cgroup.h
> +++ b/include/lin
Hello, Serge.
On Mon, Dec 07, 2015 at 05:06:16PM -0600, serge.hal...@ubuntu.com wrote:
> +/* kernfs_node_depth - compute depth from @from to @to */
> +static size_t kernfs_node_distance(struct kernfs_node *from, struct
> kernfs_node *to)
> {
> + size_t depth = 0;
>
> + BUG_ON(!to);
> +
Hello, Serge.
On Thu, Dec 03, 2015 at 04:47:06PM -0600, Serge E. Hallyn wrote:
...
> + dentry = dget(sb->s_root);
> + if (!kn->parent) // this is the root
> + return dentry;
> +
> + knparent = find_kn_ancestor_below(kn, NULL);
> + BUG_ON(!knparent);
Doing WARN_ON() and
On Wed, Dec 02, 2015 at 11:02:39AM -0600, Serge E. Hallyn wrote:
> On Wed, Dec 02, 2015 at 11:58:39AM -0500, Tejun Heo wrote:
> > On Wed, Dec 02, 2015 at 10:56:37AM -0600, Serge E. Hallyn wrote:
> > > Can it be flushed when we know that the cgroup is being pinned by
> >
On Wed, Dec 02, 2015 at 10:56:37AM -0600, Serge E. Hallyn wrote:
> Can it be flushed when we know that the cgroup is being pinned by
> a css_set? (There's either a task or a cgroup_namespace pinning it
> or we wouldn't get here)
Yeap, it can be flushed. There's no ref coming out of cgroup to the
Hello, Serge.
On Tue, Dec 01, 2015 at 03:58:53PM -0600, Serge E. Hallyn wrote:
> I mispoke before though - it's not the hierarchy's root dentry,
> but rather a dentry for a descendent cgroup which will become the
> root dentry for the new superblock. We do know that there must be
> a css_set with
Hey, Serge.
On Mon, Nov 30, 2015 at 10:07:04PM -0600, Serge E. Hallyn wrote:
> So actually the way the code is now, the first mount cannot
> be done from a non-init user namespace; and kernfs_obtain_root()
> is only called from non-init user namespace. So can we assume
> that the root dentry will
Hello, Serge.
On Mon, Nov 30, 2015 at 12:37:58PM -0600, Serge E. Hallyn wrote:
> > Yeah, I agree but the name is kinda misleading tho. The output isn't
> > really a relative path but rather absolute path against the specified
> > root. Maybe updating the function and parameter names would be
> >
Hello,
On Thu, Nov 26, 2015 at 11:25:11PM -0600, Serge E. Hallyn wrote:
> > > + /* Short-circuit the easy case - kn_to is the root node. */
> > > + if ((kn_from == kn_to) || (!kn_from && !kn_to->parent)) {
> > > + *p = '/';
> > > + *(p + 1) = '\0';
> >
> > Hmm... so if kn_from ==
Hello, Serge.
On Thu, Nov 26, 2015 at 11:17:45PM -0600, Serge E. Hallyn wrote:
> > Wouldn't it be simpler to walk dentry from kernfs root than
> > duplicating dentry instantiation?
>
> Sorry I don't think I'm following. Are you suggesting walking the
> kn->parent chain backward and doing d_looku
On Wed, Nov 25, 2015 at 07:55:53PM +, Serge Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
> > Hello, Serge.
> >
> > On Wed, Nov 25, 2015 at 12:01:56AM -0600, Serge E. Hallyn wrote:
> > > that was my goal with
> > > https://git.kernel.org/cgit/lin
Hello, Serge.
On Wed, Nov 25, 2015 at 12:01:56AM -0600, Serge E. Hallyn wrote:
> that was my goal with
> https://git.kernel.org/cgit/linux/kernel/git/sergeh/linux-security.git/commit/?h=cgroupns.v4&id=8eb75d2bb24df59e262f050dce567d2332adc5f3
> (which was sent inline earlier in this thread in resp
Hello,
On Tue, Nov 24, 2015 at 12:23:53PM -0800, Linus Torvalds wrote:
> instead (possibly just "spin_unlock_wait()" - but the explicit loop
I see. Wasn't thinking about cache traffic. Yeah, spin_unlock_wait()
seems a lot better.
> might be worth it if you then want to check the "canceling" fl
Hello,
On Mon, Nov 16, 2015 at 01:51:44PM -0600, se...@hallyn.com wrote:
> +struct dentry *kernfs_obtain_root(struct super_block *sb,
> + struct kernfs_node *kn)
> +{
> + struct dentry *dentry;
> + struct inode *inode;
> +
> + BUG_ON(sb->s_op != &kernfs_so
On Mon, Nov 16, 2015 at 01:51:45PM -0600, se...@hallyn.com wrote:
> From: Aditya Kali
>
> Signed-off-by: Aditya Kali
> Signed-off-by: Serge Hallyn
> ---
> Documentation/cgroups/namespace.txt | 142
> +++
Please refresh on top of cgroup/for-4.5 branch.
Thanks.
On Tue, Nov 24, 2015 at 11:27:28AM -0500, Tejun Heo wrote:
> > +struct cgroup *get_task_cgroup(struct task_struct *task)
Umm... is this function even used?
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger
On Mon, Nov 16, 2015 at 01:51:43PM -0600, se...@hallyn.com wrote:
> @@ -85,10 +85,27 @@ err_out:
> return ERR_PTR(err);
> }
>
> -static int cgroupns_install(struct nsproxy *nsproxy, void *ns)
> +static inline struct cgroup_namespace *to_cg_ns(struct ns_common *ns) {
> + return containe
Hello,
On Mon, Nov 16, 2015 at 01:51:42PM -0600, se...@hallyn.com wrote:
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 99096be..b3ce9d9 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -17,6 +17,9 @@
> #include
> #include
> #include
> +#inclu
Hello,
On Mon, Nov 16, 2015 at 01:51:41PM -0600, se...@hallyn.com wrote:
> From: Aditya Kali
>
> move cgroup_get() and cgroup_put() into cgroup.h so that
> they can be called from other places.
>
> Signed-off-by: Aditya Kali
> Acked-by: Serge Hallyn
> ---
> include/linux/cgroup.h | 21
Hello,
On Mon, Nov 16, 2015 at 01:51:40PM -0600, se...@hallyn.com wrote:
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index 22e3754..29f0b02 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -326,6 +326,7 @@ static inline bool css_tryget_online(struct
>
Oops, also please cc Greg Kroah-Hartman
on kernfs changes.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
On Mon, Nov 16, 2015 at 01:51:38PM -0600, se...@hallyn.com wrote:
> +static char * __must_check kernfs_path_from_node_locked(
> + struct kernfs_node *kn_from,
> + struct kernfs_node *kn_to,
> + char *buf,
> + size_t buflen)
> +{
> + char *p = buf;
> + struct kernfs_n
Hello, Petr.
On Tue, Nov 24, 2015 at 11:06:50AM +0100, Petr Mladek wrote:
> > > @@ -610,6 +625,12 @@ repeat:
> > > if (work) {
> > > __set_current_state(TASK_RUNNING);
> > > work->func(work);
> > > +
> > > + spin_lock_irq(&worker->lock);
> > > + /* Allow to qu
Hello,
On Wed, Nov 18, 2015 at 02:25:14PM +0100, Petr Mladek wrote:
> +static int
> +try_to_cancel_kthread_work(struct kthread_work *work,
> +spinlock_t *lock,
> +unsigned long *flags)
> +{
> + int ret = 0;
> +
> + if (work->t
Hello,
On Wed, Nov 18, 2015 at 02:25:12PM +0100, Petr Mladek wrote:
> @@ -610,6 +625,12 @@ repeat:
> if (work) {
> __set_current_state(TASK_RUNNING);
> work->func(work);
> +
> + spin_lock_irq(&worker->lock);
> + /* Allow to queue the work i
Hello, Eric.
On Mon, Nov 16, 2015 at 04:24:27PM -0600, Eric W. Biederman wrote:
> Does this allow mixing of cgroupfs and cgroupfs2? That is can I: "mount
> -t cgroupfs" inside a container and "mount -t cgroupfs2" outside a
> container? and still have reasonable things happen? I suspect the
> sem
Hello,
On Wed, Oct 14, 2015 at 12:20:22PM +0200, Petr Mladek wrote:
> IMHO, it would be great if it is easy to convert between the
> kthread worker and workqueues API. It will allow to choose
Sure, keep the APIs similar so that they can be easily converted back
and forth but that doesn't mean kth
Hello, Petr.
On Wed, Oct 07, 2015 at 11:21:30AM +0200, Petr Mladek wrote:
> Now, let's have one work: W, two workers: A, B, and try to queue
> the same work to the two workers at the same time:
It's a debug WARN condition to catch silly mistakes. It can have
minor race conditions.
...
> Second,
Hello,
On Fri, Oct 02, 2015 at 05:43:36PM +0200, Petr Mladek wrote:
> IMHO, we need both locks. The worker manipulates more works and
> need its own lock. We need work-specific lock because the work
> might be assigned to different workers and we need to be sure
> that the operations are really se
Hello, Petr.
On Fri, Sep 25, 2015 at 01:26:17PM +0200, Petr Mladek wrote:
> 1) PENDING state plus -EAGAIN/busy loop cycle
> -
>
> IMHO, we want to use the timer because it is an elegant solution.
> Then we must release the lock when the timer is running
Hello, Petr.
On Mon, Sep 21, 2015 at 03:03:41PM +0200, Petr Mladek wrote:
> 9th, 12th, 17th patches: convert three kthreads into the new API,
> namely: khugepaged, ring buffer benchmark, RCU gp kthreads[*]
I haven't gone through each conversion in detail but they generally
look good to me.
Hello,
On Mon, Sep 21, 2015 at 03:03:50PM +0200, Petr Mladek wrote:
> +static int khugepaged_has_work(void)
> +{
> + return !list_empty(&khugepaged_scan.mm_head) &&
> + khugepaged_enabled();
> +}
Hmmm... no biggie but this is a bit bothering.
> @@ -425,7 +447,10 @@ static ssize_t
On Mon, Sep 21, 2015 at 03:03:48PM +0200, Petr Mladek wrote:
> /**
> + * try_to_grab_pending_kthread_work - steal kthread work item from worklist,
> + * and disable irq
> + * @work: work item to steal
> + * @is_dwork: @work is a delayed_work
> + * @flags: place to store irq state
> + *
> + * Try
Hello,
On Mon, Sep 21, 2015 at 03:03:45PM +0200, Petr Mladek wrote:
...
> Note that flush() does not guarantee that the queue is empty. drain()
> is more safe. It returns when the queue is really empty. Also it warns
Maybe it'd be better to be a bit more specific. drain() is safer
because it can
On Mon, Sep 21, 2015 at 03:03:44PM +0200, Petr Mladek wrote:
> flush_kthread_worker() returns when the currently queued works are proceed.
^
processed?
> But some
Hello, Petr.
On Mon, Sep 21, 2015 at 03:03:43PM +0200, Petr Mladek wrote:
> It enforces using kthread_worker_fn() for the main thread. But I doubt
> that there are any plans to create any alternative. In fact, I think
> that we do not want any alternative main thread because it would be
> hard to
Hello,
On Wed, Aug 12, 2015 at 03:27:26PM -0500, Eric W. Biederman wrote:
> proc has always reported -ENOENT. sysfs is the odd one out.
Hmm... open(2) is clear about failure modes and ENOENT doesn't fit the
bill here. Maintaining the behavior for proc for backward
compatibility is fine but I don
> userspace application depended on stat returning i_size of 0. So modify
> make_empty_dir_inode to cause an i_size of 0 to be reported for these
> directories.
>
> Cc: sta...@vger.kernel.org
> Reproted-by: Tejun Heo
^^^
> Signed-off-by: "Eric W. Biederman"
Ack
On Tue, Aug 11, 2015 at 07:58:14PM -0500, Eric W. Biederman wrote:
> Andy Lutomirski writes:
>
> > On Tue, Aug 11, 2015 at 11:57 AM, Eric W. Biederman
> > wrote:
> >>
> >> *Boggle*
> >>
> >> The only time this should prevent anything is when in a container when
> >> you are not global root. And
Hello, Eric.
On Tue, Aug 11, 2015 at 11:04:28PM -0500, Eric W. Biederman wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > ebied...@xmission.com (Eric W. Biederman) writes:
> >
> >> I just went and attempted to reproduce this, and on RHEL6 workstation
> >> (aka my work laptop), usi
Hey,
On Tue, Aug 11, 2015 at 2:57 PM, Eric W. Biederman
wrote:
>> So, this somehow ends up confusing upstart on centos6 based systems
>> making it fail to mount tmpfs on /sys/fs/cgroup. It also skips sunrpc
>> and other mounts are different too. No idea why at this point. Can
>> we please reve
On Thu, May 14, 2015 at 12:36:30PM -0500, Eric W. Biederman wrote:
>
> This allows for better documentation in the code and
> it allows for a simpler and fully correct version of
> fs_fully_visible to be written.
>
> The mount points converted and their filesystems are:
> /sys/hypervisor/s390/
Hello,
On Wed, Jul 29, 2015 at 01:23:54PM +0200, Petr Mladek wrote:
> My plan is to make the API cleaner and hide struct kthread_worker
> definition into kthread.c. It would prevent anyone doing any hacks
> with it. BTW, we do the same with struct workqueue_struct.
I think obsessive attachment to
Hello, Petr.
On Wed, Jul 29, 2015 at 12:04:57PM +0200, Petr Mladek wrote:
> > I'm not sure full-on chained work detection is necessary here.
> > kthread worker's usages tend to be significantly simpler and draining
> > is only gonna be used for destruction.
>
> I think that it might be useful to
On Tue, Jul 28, 2015 at 04:39:31PM +0200, Petr Mladek wrote:
> +/**
> + * set_kthread_worker_scheduler - change the scheduling policy and/or RT
> + * priority of a kthread worker.
> + * @worker: target kthread_worker
> + * @policy: new policy
> + * @sched_priority: new RT priority
> + *
> + * Ret
On Tue, Jul 28, 2015 at 04:39:30PM +0200, Petr Mladek wrote:
...
> +/*
> + * set_kthread_worker_user_nice - set scheduling priority for the kthread
> worker
> + * @worker: target kthread_worker
> + * @nice: niceness value
> + */
> +void set_kthread_worker_user_nice(struct kthread_worker *worker, l
On Tue, Jul 28, 2015 at 04:39:25PM +0200, Petr Mladek wrote:
...
> -static int __noreturn rcu_gp_kthread(void *arg)
> +static void rcu_gp_kthread_func(struct kthread_work *work)
> {
> int fqs_state;
> int gf;
> unsigned long j;
> int ret;
> - struct rcu_state *rsp = arg
Hello,
On Tue, Jul 28, 2015 at 04:39:24PM +0200, Petr Mladek wrote:
> -static void khugepaged_wait_work(void)
> +static void khugepaged_wait_func(struct kthread_work *dummy)
> {
> if (khugepaged_has_work()) {
> if (!khugepaged_scan_sleep_millisecs)
> - retu
Hello,
On Tue, Jul 28, 2015 at 04:39:23PM +0200, Petr Mladek wrote:
> I would like to make cleaner kthread worker API and hide the definition
> of struct kthread_worker. It will prevent any custom hacks and make
> the API more secure.
>
> This patch provides an API to check if the worker has been
Hello,
On Tue, Jul 28, 2015 at 04:39:22PM +0200, Petr Mladek wrote:
...
> +void wakeup_and_destroy_kthread_worker(struct kthread_worker *worker)
> +{
> + struct task_struct *task = worker->task;
> +
> + if (WARN_ON(!task))
> + return;
> +
> + spin_lock_irq(&worker->lock);
>
Hello,
On Tue, Jul 28, 2015 at 04:39:20PM +0200, Petr Mladek wrote:
> +/*
> + * Test whether @work is being queued from another work
> + * executing on the same kthread.
> + */
> +static bool is_chained_work(struct kthread_worker *worker)
> +{
> + struct kthread_worker *current_worker;
> +
> +
Hey, Petr.
On Fri, Jun 12, 2015 at 03:24:40PM +0200, Petr Mladek wrote:
> > * While hibernating, freezing writeback workers and whoever else which
> > might issue IOs. This is because we have to thaw devices to issue
> > IOs to write out the prepared hibernation image. If new IOs are
> > i
Hello, Peter.
On Wed, Jun 10, 2015 at 12:40:57PM +0200, Peter Zijlstra wrote:
> > Because there's a pool of them and the workers come and go
> > dynamically. There's no way around it. The attributes just have to
> > be per-pool.
>
> Sure, but there's a few possible ways to still make that work
Hello, Petr.
On Tue, Jun 09, 2015 at 05:53:13PM +0200, Petr Mladek wrote:
> I think that the interaction with the hardware should be the reason to
> make them properly freezable. In the current state they are stopped at
> some random place, they might either miss some event from the hardware
> or
Hello, Jiri.
On Tue, Jun 09, 2015 at 02:15:24PM +0200, Jiri Kosina wrote:
> To me, the ultimate goal (*) is to make it possible for kthread to be able
> to decide whether it wants "some kind of default behavior" (however that'd
> be defined), or "ignore all", or "just handle this set of signals
Hello, Petr.
I've skimmed through the patchset and I'm not quite sure.
kthread_iterant seems to map almost one to one to kthread_worker
interface. One calls a predefined callback repeatedly while the other
queues work items which contain callback. One does nasty plumbing
tasks inbetween interati
Hello,
On Mon, Jun 08, 2015 at 12:01:07PM +0200, Petr Mladek wrote:
> BTW: What is the preferred way of freezing, please? Is it better
> to end up in the fridge or is it fine to call freezer_do_not_count();
> or set PF_NOFREEZE when it is safe?
There's no one good answer. The closest would be "d
Hello, Petr.
On Fri, Jun 05, 2015 at 05:01:06PM +0200, Petr Mladek wrote:
> Many kthreads already calls set_freezable() before they enter the main
> cycle. One of the reasons for creating iterant kthreads is to create
> a safe point for freezing and make even more kthreads properly
> freezable. Th
Hello, Petr.
On Fri, Jun 05, 2015 at 05:01:05PM +0200, Petr Mladek wrote:
> Several kthreads already handle signals some way. They do so
> in different ways, search for allow_signal().
>
> This patch allows to handle the signals in a more uniform way using
> kthread_do_signal().
>
> The main que
Hello, Petr.
On Fri, Jun 05, 2015 at 05:01:01PM +0200, Petr Mladek wrote:
> +static int kthread_iterant_fn(void *kti_ptr)
> +{
> + struct kthread_iterant *kti = kti_ptr;
> + void *data = kti->data;
> +
> + if (kti->init)
> + kti->init(data);
> +
> + do {
> +
Hey, Peter.
On Fri, Jun 05, 2015 at 06:22:16PM +0200, Peter Zijlstra wrote:
> There's a lot more problems with workqueues:
>
> - they're not regular tasks and all the task controls don't work on
>them. This means all things scheduler, like cpu-affinity, nice, and
>RT/deadline scheduling
Hello,
On Fri, Jun 05, 2015 at 05:00:59PM +0200, Petr Mladek wrote:
> Workqueue
...
> But there are many kthreads that need to cycle many times
> until some work is finished, e.g. khugepaged, virtio_balloon,
> jffs2_garbage_collect_thread. They would need to queue the
> work item repeatedly from t
On Wed, Feb 11, 2015 at 05:00:23PM +0100, Serge E. Hallyn wrote:
> We absolutely would love to use cgroup namespaces to run older
> userspace in containers. I don't know that it's actually possible
> to do both that and use unified hierarchy at the same time though,
> which is unfortunate. So an
Hey,
On Wed, Feb 11, 2015 at 12:29:20AM -0600, Eric W. Biederman wrote:
> In general namespaces are not necessary if your scope of names
> already has hierarchy. Which means that new interfaces can almost
> always be designed in such a way that you can support containers without
> needing to add
Hey,
On Tue, Feb 10, 2015 at 11:02:40PM -0600, Eric W. Biederman wrote:
> A slightly off topic comment, for where this thread has gone but
> relevant if we are talking about cgroup namespaces.
>
> If don't implement compatibility with existing userspace, they get a
> nack. A backwards-incompatib
Hello,
On Wed, Feb 11, 2015 at 05:29:42AM +0100, Serge E. Hallyn wrote:
> > There shouldn't be a "freezer" cgroup. The processes are categorized
> > according to their logical structure and controllers are applied to
> > the hierarchy as necessary.
>
> But there can well be cgroups for which onl
On Wed, Feb 11, 2015 at 04:46:16AM +0100, Serge E. Hallyn wrote:
> 1. Hierarchy_num in /proc/cgroups and /proc/self/cgroup start at 0. Used
> to start with 1. I expect many userspace parsers to be broken by this.
This is intentional. The unified hierarchy will always have the
hierarchy number z
On Wed, Jan 07, 2015 at 05:27:38PM -0600, Eric W. Biederman wrote:
> >> The -o SUBSYS option doesn't exist. Jesus, at least get yourself
> >> familiar with the basics before claiming random stuff.
>
> Oh let's see I got that command line option out of /proc/mounts and yes
> it works. Perhaps it
On Wed, Jan 07, 2015 at 05:09:53PM -0600, Eric W. Biederman wrote:
> I may have mistyped the manual command line configuration for specifying
> which controllers appear on a mount point does not alter my point.
Hmmm? You were talking about the old hierarchies?
> The old options to enable selecti
On Wed, Jan 07, 2015 at 05:02:17PM -0600, Eric W. Biederman wrote:
> Ignoring namespace details for a moment. The following should be
> possible with a unified hierarchy. If it is not it is a show stopper
> of a regression.
The -o SUBSYS option doesn't exist. Jesus, at least get yourself
familia
On Wed, Jan 07, 2015 at 04:14:40PM -0600, Eric W. Biederman wrote:
> I see what you mean. If it is indeed the case than a mount of cgroupfs
> using the unified hiearchy and can not specify which controllers are
> present under that mount that very significant bug and presents a very
> significant
Hello, Aditya.
On Mon, Nov 03, 2014 at 03:12:28PM -0800, Aditya Kali wrote:
> I think the sane-behavior flag is only temporary and will be removed
> anyways, right? So I didn't bother asking user to supply it. But I can
> make the change as you suggested. We just have to make sure that tasks
> ins
Hello, Aditya.
On Mon, Nov 03, 2014 at 02:43:47PM -0800, Aditya Kali wrote:
> I agree that this is effectively bind-mounting, but doing this in kernel
> makes it really convenient for the userspace. The process that sets up the
> container doesn't need to care whether it should bind-mount cgroupfs
Hello,
On Wed, Oct 22, 2014 at 11:37:55AM -0700, Aditya Kali wrote:
...
> Actually, there is no right answer here. Our options are:
> * show relative path
> -- this will break userspace as /proc//cgroup does not show
> relative paths today. This is also very ambiguous (is it relative to
> cgroupns
91 matches
Mail list logo
