Hello,
On Sat, May 17, 2014 at 05:45:40PM -0500, Christoph Lameter wrote:
> On Fri, 16 May 2014, Tejun Heo wrote:
>
> > > Make the uevent stuff work on all of sysfs?
> >
> > I don't know. Maybe. Likely a lot more work involving user space
> > changes tho. Also, it runs contrary to what we've b
On Fri, 16 May 2014, Tejun Heo wrote:
> > Make the uevent stuff work on all of sysfs?
>
> I don't know. Maybe. Likely a lot more work involving user space
> changes tho. Also, it runs contrary to what we've been doing to other
> top-level cgroup directories. Any reason not to do, say,
> /sys/d
Hello,
On Fri, May 16, 2014 at 06:02:55PM -0500, Christoph Lameter wrote:
> On Fri, 16 May 2014, Tejun Heo wrote:
> > So, the thing is sysfs has been collecting everything under
> > /sys/devices because other top level directories added complexity
> > while missing out on basic event mechanism. If
On Fri, 16 May 2014, Tejun Heo wrote:
>
> So, the thing is sysfs has been collecting everything under
> /sys/devices because other top level directories added complexity
> while missing out on basic event mechanism. If you look at other
Make the uevent stuff work on all of sysfs?
--
To unsubscri
Hello, again.
On Fri, May 16, 2014 at 3:34 PM, Tejun Heo wrote:
> On Fri, May 16, 2014 at 3:32 PM, Christoph Lameter wrote:
>> It sets a bad precedent. So move to /sys/kernel/workqueue and lets have a
>> symlink that goes back?
>
> Hmm... I don't think it's a good idea to lose uevent. It's an in
On Fri, May 16, 2014 at 3:32 PM, Christoph Lameter wrote:
> It sets a bad precedent. So move to /sys/kernel/workqueue and lets have a
> symlink that goes back?
Hmm... I don't think it's a good idea to lose uevent. It's an integral
part in configuring sysfs. Wouldn't it make more sense to move
/sy
On Fri, 16 May 2014, Tejun Heo wrote:
> > Could we fix that? A workqueue is not a device but more a kernel setting.
> >
> > /sys/kernel/workqueue/ ?
>
> Right, that could have been more in line with slab files. It's
> already too late tho. This has been exposed for quite a while now.
> Urgh.
On Fri, May 16, 2014 at 03:00:42PM -0400, Tejun Heo wrote:
> > /sys/kernel/workqueue/ ?
>
> Right, that could have been more in line with slab files. It's
> already too late tho. This has been exposed for quite a while now.
> Urgh...
Okay, another difference, so things under /sys/devices ge
On Fri, May 16, 2014 at 01:52:48PM -0500, Christoph Lameter wrote:
> On Fri, 16 May 2014, Tejun Heo wrote:
>
> > On Fri, May 16, 2014 at 12:52:26PM -0500, Christoph Lameter wrote:
> > > On Fri, 16 May 2014, Frederic Weisbecker wrote:
> > >
> > > > It works on a lower-level than the per WQ_SYSFS wo
On Fri, 16 May 2014, Tejun Heo wrote:
> On Fri, May 16, 2014 at 12:52:26PM -0500, Christoph Lameter wrote:
> > On Fri, 16 May 2014, Frederic Weisbecker wrote:
> >
> > > It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
> > > such that the effective cpumask applied for a give
On Fri, May 16, 2014 at 12:52:26PM -0500, Christoph Lameter wrote:
> On Fri, 16 May 2014, Frederic Weisbecker wrote:
>
> > It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
> > such that the effective cpumask applied for a given unbound workqueue is
> > the intersection of /
On Fri, 16 May 2014, Frederic Weisbecker wrote:
> It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
> such that the effective cpumask applied for a given unbound workqueue is
> the intersection of /sys/devices/virtual/workqueue/$WORKQUEUE/cpumask and
> the new /sys/devices/v
Create a cpumask that limit the affinity of all unbound workqueues.
This cpumask is controlled though a file at the root of the workqueue
sysfs directory.
It works on a lower-level than the per WQ_SYSFS workqueues cpumask files
such that the effective cpumask applied for a given unbound workqueue
13 matches
Mail list logo
