From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: schedulers and topology exposing questions Date: Thu, 28 Jan 2016 22:27:02 -0500 Message-ID: <20160129032701.GA20981@x230.dumpdata.com> References: <20160122165423.GA8595@elena.ufimtseva> <56A756C0.20501@citrix.com> <20160127143303.GA1094@char.us.oracle.com> <56A8DDC9.4080307@citrix.com> <20160127152701.GF552@char.us.oracle.com> <1453993857.26691.32.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <1453993857.26691.32.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Elena Ufimtseva , george.dunlap@eu.citrix.com, George Dunlap , xen-devel@lists.xen.org, joao.m.martins@oracle.com, boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org On Thu, Jan 28, 2016 at 03:10:57PM +0000, Dario Faggioli wrote: > On Wed, 2016-01-27 at 10:27 -0500, Konrad Rzeszutek Wilk wrote: > > On Wed, Jan 27, 2016 at 03:10:01PM +0000, George Dunlap wrote: > > >=A0 > > > I'm not sure I understand the situation right, but it sounds a bit > > > like > > > what you're seeing is just a quirk of the fact that Linux doesn't > > > always > > > send IPIs to wake other processes up (either by design or by > > > accident), > > = > > It does and it does not :-) > > = > > > but relies on scheduling timers to check for work to > > > do.=A0=A0Presumably > > = > > It .. I am not explaining it well. The Linux kernel scheduler when > > called for 'schedule' (from the UDP sendmsg) would either pick the > > next > > appliction and do a context swap - of if there were none - go to > > sleep. > > [Kind of - it also may do an IPI to the other CPU if requested ,but > > that requires > > some hints from underlaying layers] > > Since there were only two apps on the runqueue - udp sender and udp > > receiver > > it would run them back-to back (this is on baremetal) > > = > > However if SMT was not exposed - the Linux kernel scheduler would put > > those > > on each CPU runqueue. Meaning each CPU only had one app on its > > runqueue. > > = > > Hence no need to do an context switch. > > [unless you modified the UDP message to have a timeout, then it would > > send an IPI] > > > So, may I ask what piece of (Linux) code are we actually talking about? > Because I had a quick look, and could not find where what you describe > happens.... udp_recvmsg->__skb_recv_datagram->sock_rcvtimeo->schedule_timeout The sk_rcvtimeo is MAX_SCHEDULE_TIMEOUT but you can alter the UDP by having a diffrent timeout. And MAX_SCHEDULE_TIMEOUT when it eventually calls 'schedule()' just goes to sleep (HLT) and eventually gets woken up VIRQ_TIMER. The other side - udp_sendmsg is more complex, and I don't seem to have the stacktrace. = > = > Thanks and Regards, > Dario > -- = > <> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > =