Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1310000

Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth

Path csiph.com!news.freedyn.net!aioe.org!bofh.it!news.nic.it!robomod
From Luca Abeni <luca.abeni@unitn.it>
Newsgroups linux.kernel
Subject Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth
Date Fri, 15 Jan 2016 10:50:02 +0100
Message-ID <qR9b4-4eJ-11@gated-at.bofh.it> (permalink)
References <qQS0x-uX-3@gated-at.bofh.it> <qQSae-yO-17@gated-at.bofh.it> <qQWdQ-3jT-21@gated-at.bofh.it> <qR7VE-3qX-23@gated-at.bofh.it> <qR8oG-3Fn-19@gated-at.bofh.it>
X-Original-To Peter Zijlstra <peterz@infradead.org>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=unitn-it.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=h7AnZux6dVt7Z4wNUtjHi3e6PB/ef7liLVdeJJvj2O0=; b=UG8+Kvw0BX9PnV00MaO1NfQ0w+tYuGB9iykvvnuopvLKPeKmBaeg5Ya+7sUAxnkWLm dhirMqL+b/uoXl0NiEgL50zuURQau7tj4PObk38T+AVILAd6jRs+UqSPKCqCpDwVUI+j iChu1sI5cvmcf61iZa4zO2KroaaegiJPNSZ5AlI25j1BMN7XQHbJu+2nkzgEIrFyZn3G mUzLPZZiUDrU/6hcpxb+j7GZpMINnMiTxN8Izu+J6q1MPlRIn6Pmkr9a5mmFVBhbw6zm /1W6MEEDN8/I5ot2+KT4wYwlc8L/UJsqnNnetBdRbuGrk1xvjy1+hSBsdLZJgFVjHv9e OxvA==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=h7AnZux6dVt7Z4wNUtjHi3e6PB/ef7liLVdeJJvj2O0=; b=U7hPsDPg+nSKxCgoZ4sXJYScuyC3LYq1YLQAddaeMbDlhvz0ldzkJf55zxR3mngesZ 6ogmQvpdYsalVDYdfBIap1UoYgSmbLiaobCLQ0Lm4J2Y/cL6noiKM7REevdOJkeEamEb 8skZ1fVGXYHhCt1nlBZkzOYn1ZVQMsfuasOsRYZZvhehFp77p5cKzeOj0ruYgu0awE0g vSa7HZ99fAVDlK9ap5wS0FVdgTYa/ZtiLfnuN4bIPvVyjqv8OriwJ44zQSuvHUcS3mtD ZGSCqmc5V8C0S0IuQt715JI0j2B1NqTS1g0QerC7R7KgN5beEOiW+FO0Mfju4NzoZIGV i/gQ==
X-Gm-Message-State ALoCoQko1BVU3WH0fRwhesYZBceF8LZ66Iy+l+keA80W0UH+vu60zb9T10K6e6gOzOCkLwVGIHvsGT2eS6y8t0tzg9G/k+QSwg==
X-Received by 10.194.119.232 with SMTP id kx8mr10233104wjb.94.1452851386010; Fri, 15 Jan 2016 01:49:46 -0800 (PST)
X-Mailer Claws Mail 3.8.0 (GTK+ 2.24.10; i686-pc-linux-gnu)
MIME-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 8BIT
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 29
Organization linux.* mail to news gateway
X-Original-Cc linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>, Juri Lelli <juri.lelli@arm.com>
X-Original-Date Fri, 15 Jan 2016 10:49:37 +0100
X-Original-Message-ID <20160115104937.6a11cdc4@luca-1225C>
X-Original-References <1452785094-3086-1-git-send-email-luca.abeni@unitn.it> <1452785094-3086-9-git-send-email-luca.abeni@unitn.it> <20160114195904.GH6357@twins.programming.kicks-ass.net> <5698ABFD.1040704@unitn.it> <20160115085004.GE3421@worktop>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1310000

Show key headers only | View raw


On Fri, 15 Jan 2016 09:50:04 +0100
Peter Zijlstra <peterz@infradead.org> wrote:
[...]
> The trouble is with interfaces. Once we expose them we're stuck with
> them. And from that POV I think an explicit SCHED_OTHER server (or a
> minimum budget for a slack time scheme) makes more sense.
> 
> It provides this same information while also providing more benefit,
> no?
From an interface point of view, I agree.

> > >That would maybe fit in nicely with the DL based FIFO/RR servers
> > >from this other pending project.
> > Yes, this reminds me about the half-finished patch for RT
> > throttling using SCHED_DEADLINE... But that patch needs much more
> > work IMHO.
> 
> IIRC two years ago at RTLWS there was a presentation that the SMP
> issues were 'solved' and they would be posting the patches 'soon'. 
Do you mean this paper?
http://retis.sssup.it/~nino/publication/rtlws14bdm.pdf

I started from that patch, and I have something that "basically works",
but I am still discussing some theoretical and implementation issues
with the paper's authors.



				Luca

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-14 16:40 +0100
  Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-01-14 21:00 +0100
    Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 09:30 +0100
      Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-01-15 10:00 +0100
        Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Luca Abeni <luca.abeni@unitn.it> - 2016-01-15 10:50 +0100
        Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth luca abeni <luca.abeni@unitn.it> - 2016-01-26 14:00 +0100
          Re: [RFC 8/8] Do not reclaim the whole CPU bandwidth Peter Zijlstra <peterz@infradead.org> - 2016-01-27 15:50 +0100

csiph-web