On 8/13/2013 6:26 PM, Andrew Morton wrote:
> On Tue, 13 Aug 2013 18:13:48 -0400 Chris Metcalf wrote:
>
>> On 8/13/2013 5:13 PM, Andrew Morton wrote:
>>> On Tue, 13 Aug 2013 16:59:54 -0400 Chris Metcalf
>>> wrote:
>>>
> Then again, why does this patchset exist? It's a performance
> optim
Hello, Andrew.
On Tue, Aug 13, 2013 at 03:47:40PM -0700, Andrew Morton wrote:
> > Well, I don't buy that either. Callback based interface has its
> > issues.
>
> No it hasn't. It's a common and simple technique which we all understand.
It sure has its uses but it has receded some of its former
On Tue, 13 Aug 2013 18:33:04 -0400 Tejun Heo wrote:
> Hello, Andrew.
>
> On Tue, Aug 13, 2013 at 03:18:05PM -0700, Andrew Morton wrote:
> > I don't buy it. The callback simply determines whether "we need to
> > schuedule work on this cpu". It's utterly simple. Nobody will have
> > trouble und
Hello, Andrew.
On Tue, Aug 13, 2013 at 03:18:05PM -0700, Andrew Morton wrote:
> I don't buy it. The callback simply determines whether "we need to
> schuedule work on this cpu". It's utterly simple. Nobody will have
> trouble understanding or using such a thing.
Well, I don't buy that either.
On Tue, 13 Aug 2013 18:13:48 -0400 Chris Metcalf wrote:
> On 8/13/2013 5:13 PM, Andrew Morton wrote:
> > On Tue, 13 Aug 2013 16:59:54 -0400 Chris Metcalf
> > wrote:
> >
> >>> Then again, why does this patchset exist? It's a performance
> >>> optimisation so presumably someone cares. But not e
On Tue, 13 Aug 2013 18:07:00 -0400 Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 13, 2013 at 02:16:21PM -0700, Andrew Morton wrote:
> > I've yet to see any evidence that callback APIs have been abused and
> > I've yet to see any reasoning which makes me believe that this one will
> > be abused.
>
>
On 8/13/2013 5:13 PM, Andrew Morton wrote:
> On Tue, 13 Aug 2013 16:59:54 -0400 Chris Metcalf wrote:
>
>>> Then again, why does this patchset exist? It's a performance
>>> optimisation so presumably someone cares. But not enough to perform
>>> actual measurements :(
>> The patchset exists becaus
Hello,
On Tue, Aug 13, 2013 at 02:16:21PM -0700, Andrew Morton wrote:
> I've yet to see any evidence that callback APIs have been abused and
> I've yet to see any reasoning which makes me believe that this one will
> be abused.
Well, off the top of my head.
* In general, it's clunkier. Callback
On Tue, 13 Aug 2013 17:07:19 -0400 Tejun Heo wrote:
> > I don't recall seeing such abuse. It's a very common and powerful
> > tool, and not implementing it because some dummy may abuse it weakens
> > the API for all non-dummies. That allocation is simply unneeded.
>
> More powerful and flexibl
On Tue, 13 Aug 2013 16:59:54 -0400 Chris Metcalf wrote:
> >
> > Then again, why does this patchset exist? It's a performance
> > optimisation so presumably someone cares. But not enough to perform
> > actual measurements :(
>
> The patchset exists because of the difference between zero overhea
Hello,
On Tue, Aug 13, 2013 at 01:31:35PM -0700, Andrew Morton wrote:
> > the logical thing to do
> > would be pre-allocating per-cpu buffers instead of depending on
> > dynamic allocation. Do the invocations need to be stackable?
>
> schedule_on_each_cpu() calls should if course happen concurre
On 8/13/2013 3:35 PM, Andrew Morton wrote:
> He may be
> old and wrinkly, but I do suggest that the guy who wrote and maintains
> that code could have got a cc.
Sorry about that - I just went by what MAINTAINERS shows. There's no
specific maintainer listed for the swap code. I probably should h
On Tue, 13 Aug 2013 16:19:58 -0400 Tejun Heo wrote:
> Hello,
>
> On Tue, Aug 13, 2013 at 12:35:12PM -0700, Andrew Morton wrote:
> > I don't know how lots-of-kmallocs compares with alloc_percpu()
> > performance-wise.
>
> If this is actually performance sensitive,
I've always assumed that it is
Hello,
On Tue, Aug 13, 2013 at 12:35:12PM -0700, Andrew Morton wrote:
> I don't know how lots-of-kmallocs compares with alloc_percpu()
> performance-wise.
If this is actually performance sensitive, the logical thing to do
would be pre-allocating per-cpu buffers instead of depending on
dynamic all
On Mon, 12 Aug 2013 21:53:11 -0400 Chris Metcalf wrote:
> On 8/12/2013 5:05 PM, Andrew Morton wrote:
> >> @@ -683,7 +693,32 @@ static void lru_add_drain_per_cpu(struct work_struct
> >> *dummy)
> >> */
> >> int lru_add_drain_all(void)
> >> {
> >> - return schedule_on_each_cpu(lru_add_drain_p
On 8/12/2013 5:05 PM, Andrew Morton wrote:
> On Wed, 7 Aug 2013 16:52:22 -0400 Chris Metcalf wrote:
>
>> This change makes lru_add_drain_all() only selectively interrupt
>> the cpus that have per-cpu free pages that can be drained.
>>
>> This is important in nohz mode where calling mlockall(), for
On Wed, 7 Aug 2013 16:52:22 -0400 Chris Metcalf wrote:
> This change makes lru_add_drain_all() only selectively interrupt
> the cpus that have per-cpu free pages that can be drained.
>
> This is important in nohz mode where calling mlockall(), for
> example, otherwise will interrupt every core u
This change makes lru_add_drain_all() only selectively interrupt
the cpus that have per-cpu free pages that can be drained.
This is important in nohz mode where calling mlockall(), for
example, otherwise will interrupt every core unnecessarily.
Signed-off-by: Chris Metcalf
---
v4: don't lose pos
18 matches
Mail list logo
