On Tue, 2015-05-26 at 15:51 -0400, Chris Metcalf wrote:
> On balance I suspect it's still better to make command line arguments
> handle the common cases most succinctly.
I prefer user specifies precisely, but yeah, that entails more typing.
Idle curiosity: can SGI monster from hell boot a NO_
Thanks for the clarification, and sorry for the slow reply; I had a busy
week of meetings last week, and then the long weekend in the U.S.
On 05/15/2015 02:44 PM, Mike Galbraith wrote:
Just because the nohz_full feature itself is currently static is no
reason to put users thereof in a straight j
On Fri, 2015-05-15 at 11:05 -0400, Chris Metcalf wrote:
> On 05/11/2015 09:47 PM, Mike Galbraith wrote:
> > On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
> >> On 05/11/2015 03:19 PM, Mike Galbraith wrote:
> >>> I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
> >>> th
On 05/12/2015 06:46 AM, Peter Zijlstra wrote:
On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
Please lets get NO_HZ_FULL up to par. That should be the main focus.
ACK, much of this dataplane stuff is (useful) hacks working around the
fact that nohz_full just isn't complete.
T
On 05/11/2015 09:47 PM, Mike Galbraith wrote:
On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
On 05/11/2015 03:19 PM, Mike Galbraith wrote:
I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
that old static isolcpus was_supposed_ to crawl off and die, I know
beyond d
On Tue, May 12, 2015 at 02:34:40PM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> > On Tue, May 12, 2015 at 11:10:32AM +0200, Ingo Molnar wrote:
> > >
> > > So I'd vote for Frederic's CONFIG_ISOLATION=y, mostly because this
> > > is a high level kernel feature, so it won't conflict
On Mon, May 11, 2015 at 03:52:37PM -0400, Chris Metcalf wrote:
> On 05/09/2015 03:19 AM, Andy Lutomirski wrote:
> >Naming aside, I don't think this should be a per-task flag at all. We
> >already have way too much overhead per syscall in nohz mode, and it
> >would be nice to get the per-syscall ov
* Peter Zijlstra wrote:
> On Tue, May 12, 2015 at 02:34:40PM +0200, Ingo Molnar wrote:
>
> > Yes, that's what I meant: CONFIG_ISOLATION would trigger what is
> > NO_HZ_FULL today - we could possibly even remove CONFIG_NO_HZ_FULL
> > as an individual Kconfig option?
>
> Ah, as a rename of nohz
On Tue, May 12, 2015 at 02:34:40PM +0200, Ingo Molnar wrote:
> Yes, that's what I meant: CONFIG_ISOLATION would trigger what is
> NO_HZ_FULL today - we could possibly even remove CONFIG_NO_HZ_FULL as
> an individual Kconfig option?
Ah, as a rename of nohz_full, sure that might work.
--
To unsubs
* Peter Zijlstra wrote:
> On Tue, May 12, 2015 at 11:10:32AM +0200, Ingo Molnar wrote:
> >
> > So I'd vote for Frederic's CONFIG_ISOLATION=y, mostly because this
> > is a high level kernel feature, so it won't conflict with
> > isolation concepts in lower level subsystems such as IOMMU
> > i
On Tue, May 12, 2015 at 11:10:32AM +0200, Ingo Molnar wrote:
>
> So I'd vote for Frederic's CONFIG_ISOLATION=y, mostly because this is
> a high level kernel feature, so it won't conflict with isolation
> concepts in lower level subsystems such as IOMMU isolation - and other
> higher level featu
On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
>
> Please lets get NO_HZ_FULL up to par. That should be the main focus.
>
ACK, much of this dataplane stuff is (useful) hacks working around the
fact that nohz_full just isn't complete.
--
To unsubscribe from this list: send the
* Chris Metcalf wrote:
> - ISOLATION (Frederic). I like this but it conflicts with other uses
> of "isolation" in the kernel: cgroup isolation, lru page isolation,
> iommu isolation, scheduler isolation (at least it's a superset of
> that one), etc. Also, we're not exactly isolating a ta
On Tue, 2015-05-12 at 03:47 +0200, Mike Galbraith wrote:
> On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
> > On 05/11/2015 03:19 PM, Mike Galbraith wrote:
> > > I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
> > > that old static isolcpus was_supposed_ to crawl off
On Mon, 2015-05-11 at 15:25 -0400, Chris Metcalf wrote:
> On 05/11/2015 03:19 PM, Mike Galbraith wrote:
> > I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
> > that old static isolcpus was_supposed_ to crawl off and die, I know
> > beyond doubt that having isolated a cpu as w
On May 12, 2015 4:54 AM, "Chris Metcalf" wrote:
>
> (Oops, resending and forcing html off.)
>
>
> On 05/09/2015 03:19 AM, Andy Lutomirski wrote:
>>
>> Naming aside, I don't think this should be a per-task flag at all. We
>> already have way too much overhead per syscall in nohz mode, and it
>> wo
(Oops, resending and forcing html off.)
On 05/09/2015 03:19 AM, Andy Lutomirski wrote:
Naming aside, I don't think this should be a per-task flag at all. We
already have way too much overhead per syscall in nohz mode, and it
would be nice to get the per-syscall overhead as low as possible. We
On 05/11/2015 03:19 PM, Mike Galbraith wrote:
I really shouldn't have acked nohz_full -> isolcpus. Beside the fact
that old static isolcpus was_supposed_ to crawl off and die, I know
beyond doubt that having isolated a cpu as well as you can definitely
does NOT imply that said cpu should become
On Mon, 2015-05-11 at 17:36 +0200, Frederic Weisbecker wrote:
> I expect some Real Time users may want this kind of dataplane mode where a
> syscall
> or whatever sleeps until the system is ready to provide the guarantee that no
> disturbance is going to happen for a given time. I'm not sure HPC
On Mon, 11 May 2015 14:09:59 -0400
Chris Metcalf wrote:
> Steven writes:
> > All kidding aside, I think this is the real answer. We don't need a new
> > NO_HZ, we need to make NO_HZ_FULL work. Right now it doesn't do exactly
> > what it was created to do. That should be fixed.
>
> The claim I'm
A bunch of issues have been raised by various folks (thanks!) and
I'll try to break them down and respond to them in a few different
emails. This email is just about the issue of naming and whether the
proposed patch series should even have its own "name" or just be part
of NO_HZ_FULL.
First, I
On Mon, 11 May 2015 19:33:06 +0200
Frederic Weisbecker wrote:
> On Mon, May 11, 2015 at 10:27:44AM -0700, Andrew Morton wrote:
> > On Mon, 11 May 2015 10:19:16 -0700 "Paul E. McKenney"
> > wrote:
> >
> > > On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
> > > >
> > > > NO_HZ_L
On Mon, May 11, 2015 at 10:27:44AM -0700, Andrew Morton wrote:
> On Mon, 11 May 2015 10:19:16 -0700 "Paul E. McKenney"
> wrote:
>
> > On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
> > >
> > > NO_HZ_LEAVE_ME_THE_FSCK_ALONE!
> >
> > NO_HZ_OVERFLOWING?
>
> Actually, "NO_HZ" sho
On Mon, 11 May 2015 10:19:16 -0700 "Paul E. McKenney"
wrote:
> On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
> >
> > NO_HZ_LEAVE_ME_THE_FSCK_ALONE!
>
> NO_HZ_OVERFLOWING?
Actually, "NO_HZ" shouldn't appear in the name at all. The objective
is to permit userspace to execute
On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
>
> NO_HZ_LEAVE_ME_THE_FSCK_ALONE!
NO_HZ_OVERFLOWING?
Kconfig naming controversy aside, I believe this patchset is addressing
a real need. Might need additional adjustment, but something useful.
On Mon, May 11, 2015 at 08:57:59AM -0400, Steven Rostedt wrote:
>
> NO_HZ_LEAVE_ME_THE_FSCK_ALONE!
>
>
> On Sat, 9 May 2015 09:05:38 +0200
> Ingo Molnar wrote:
>
> > So I think we should either rename NO_HZ_FULL to NO_HZ_PURE, or keep
> > it at NO_HZ_FULL: because the intention of NO_HZ_FULL
NO_HZ_LEAVE_ME_THE_FSCK_ALONE!
On Sat, 9 May 2015 09:05:38 +0200
Ingo Molnar wrote:
> So I think we should either rename NO_HZ_FULL to NO_HZ_PURE, or keep
> it at NO_HZ_FULL: because the intention of NO_HZ_FULL was always to be
> such a 'zero overhead' mode of operation, where if user-space
; Paul E. McKenney; Christoph Lameter; Srivatsa S. Bhat;
> linux-...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH 0/6] support "dataplane" mode for nohz_full
>
> On Sat, 2015-05-09 at 09:05 +0200, Ingo Molnar wrote:
>
On Sat, 2015-05-09 at 09:05 +0200, Ingo Molnar wrote:
> * Andrew Morton wrote:
>
> > On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote:
> >
> > > On 5/8/2015 5:22 PM, Steven Rostedt wrote:
> > > > On Fri, 8 May 2015 14:18:24 -0700
> > > > Andrew Morton wrote:
> > > >
> > > >> On Fri, 8 May
On Sat, May 9, 2015 at 12:05 AM, Ingo Molnar wrote:
>
> * Andrew Morton wrote:
>
>> On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote:
>>
>> > On 5/8/2015 5:22 PM, Steven Rostedt wrote:
>> > > On Fri, 8 May 2015 14:18:24 -0700
>> > > Andrew Morton wrote:
>> > >
>> > >> On Fri, 8 May 2015 13
* Andrew Morton wrote:
> On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote:
>
> > On 5/8/2015 5:22 PM, Steven Rostedt wrote:
> > > On Fri, 8 May 2015 14:18:24 -0700
> > > Andrew Morton wrote:
> > >
> > >> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf
> > >> wrote:
> > >>
> > >>> A prc
On Fri, 8 May 2015 19:11:10 -0400 Chris Metcalf wrote:
> On 5/8/2015 5:22 PM, Steven Rostedt wrote:
> > On Fri, 8 May 2015 14:18:24 -0700
> > Andrew Morton wrote:
> >
> >> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf
> >> wrote:
> >>
> >>> A prctl() option (PR_SET_DATAPLANE) is added
> >> D
On 5/8/2015 5:22 PM, Steven Rostedt wrote:
On Fri, 8 May 2015 14:18:24 -0700
Andrew Morton wrote:
On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf wrote:
A prctl() option (PR_SET_DATAPLANE) is added
Dumb question: what does the term "dataplane" mean in this context? I
can't see the relatio
On Fri, 8 May 2015 14:18:24 -0700
Andrew Morton wrote:
> On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf wrote:
>
> > A prctl() option (PR_SET_DATAPLANE) is added
>
> Dumb question: what does the term "dataplane" mean in this context? I
> can't see the relationship between those words and wha
On Fri, 8 May 2015 13:58:41 -0400 Chris Metcalf wrote:
> A prctl() option (PR_SET_DATAPLANE) is added
Dumb question: what does the term "dataplane" mean in this context? I
can't see the relationship between those words and what this patch
does.
--
To unsubscribe from this list: send the line "
The existing nohz_full mode does a nice job of suppressing extraneous
kernel interrupts for cores that desire it. However, there is a need
for a more deterministic mode that rigorously disallows kernel
interrupts, even at a higher cost in user/kernel transition time:
for example, high-speed networ
36 matches
Mail list logo