On Wed, Aug 05, 2015 at 07:10:57PM +0200, Oleg Nesterov wrote:
> On 07/27, Frederic Weisbecker wrote:
> >
> > Hence those two debatable changes:
> >
> > _ We would like to use generic workqueues. System unbound workqueues are
> > a very good candidate but they are not wide affine, only node
On 07/27, Frederic Weisbecker wrote:
>
> Hence those two debatable changes:
>
> _ We would like to use generic workqueues. System unbound workqueues are
> a very good candidate but they are not wide affine, only node affine.
> Now probably a node is enough to perform many parallel kmod jobs.
>
On 07/27, Frederic Weisbecker wrote:
Hence those two debatable changes:
_ We would like to use generic workqueues. System unbound workqueues are
a very good candidate but they are not wide affine, only node affine.
Now probably a node is enough to perform many parallel kmod jobs.
_ We
On Wed, Aug 05, 2015 at 07:10:57PM +0200, Oleg Nesterov wrote:
On 07/27, Frederic Weisbecker wrote:
Hence those two debatable changes:
_ We would like to use generic workqueues. System unbound workqueues are
a very good candidate but they are not wide affine, only node affine.
Now
On Tue, Jul 28, 2015 at 02:01:14PM -0400, Tejun Heo wrote:
> Hello, Frederic.
>
> On Mon, Jul 27, 2015 at 11:05:41PM +0200, Frederic Weisbecker wrote:
> > > IMHO, system_wq should be fine and if it isn't turning off numa
> > > affinity or raising max worker limit later is pretty trivial.
> >
> >
Hello, Frederic.
On Mon, Jul 27, 2015 at 11:05:41PM +0200, Frederic Weisbecker wrote:
> > IMHO, system_wq should be fine and if it isn't turning off numa
> > affinity or raising max worker limit later is pretty trivial.
>
> That's what I think too. How many workers system_unbound_wq can handle?
On Tue, Jul 28, 2015 at 02:01:14PM -0400, Tejun Heo wrote:
Hello, Frederic.
On Mon, Jul 27, 2015 at 11:05:41PM +0200, Frederic Weisbecker wrote:
IMHO, system_wq should be fine and if it isn't turning off numa
affinity or raising max worker limit later is pretty trivial.
That's what
Hello, Frederic.
On Mon, Jul 27, 2015 at 11:05:41PM +0200, Frederic Weisbecker wrote:
IMHO, system_wq should be fine and if it isn't turning off numa
affinity or raising max worker limit later is pretty trivial.
That's what I think too. How many workers system_unbound_wq can handle? If
On Mon, Jul 27, 2015 at 02:48:40PM -0400, Tejun Heo wrote:
> On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote:
> > Hence those two debatable changes:
> >
> > _ We would like to use generic workqueues. System unbound workqueues are
> > a very good candidate but they are not
On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote:
> Hence those two debatable changes:
>
> _ We would like to use generic workqueues. System unbound workqueues are
> a very good candidate but they are not wide affine, only node affine.
> Now probably a node is enough to
This patchset does a bunch of cleanups and converts khelper to use
system unbound workqueues. The 3 first patches should be uncontroversial.
The last 2 patches are debatable.
Kmod creates kernel threads that perform userspace jobs and we want
those to have a large affinity in order not to contend
This patchset does a bunch of cleanups and converts khelper to use
system unbound workqueues. The 3 first patches should be uncontroversial.
The last 2 patches are debatable.
Kmod creates kernel threads that perform userspace jobs and we want
those to have a large affinity in order not to contend
On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote:
Hence those two debatable changes:
_ We would like to use generic workqueues. System unbound workqueues are
a very good candidate but they are not wide affine, only node affine.
Now probably a node is enough to perform
On Mon, Jul 27, 2015 at 02:48:40PM -0400, Tejun Heo wrote:
On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote:
Hence those two debatable changes:
_ We would like to use generic workqueues. System unbound workqueues are
a very good candidate but they are not wide
14 matches
Mail list logo
