From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v2 2/2] sched_credit2.c: runqueue_per_core code Date: Wed, 18 Mar 2015 16:08:28 +0000 Message-ID: <5509A2FC.2010501@eu.citrix.com> References: <20150313181109.GA3179@gmail.com> <55032C85.6090805@citrix.com> <550336EE.60909@eu.citrix.com> <5506DF40020000780006A407@mail.emea.novell.com> <5506D1E1.8050404@eu.citrix.com> <5506E11F020000780006A426@mail.emea.novell.com> <1426616308.32500.98.camel@citrix.com> <55093DD1020000780006B1F2@mail.emea.novell.com> <1426668836.2560.13.camel@citrix.com> <55099940.7080007@eu.citrix.com> <5509AEFF020000780006B465@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5509AEFF020000780006B465@mail.emea.novell.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: Jan Beulich Cc: Andrew Cooper , Dario Faggioli , "xen-devel@lists.xen.org" , George.Dunlap@citrix.com, "uma.sharma523@gmail.com" List-Id: xen-devel@lists.xenproject.org On 03/18/2015 03:59 PM, Jan Beulich wrote: >>>> On 18.03.15 at 16:26, wrote: >> In both cases there's a slight risk in using system_state to determine >> whether to rely on cpu_data[] or not, because there's actually a window >> for each processor after system_state == SYS_STATE_smp_boot where >> cpu_data[] is *not* initialized, but it's not obvious from looking at >> the data itself. If the callback mechanisms ever change order with the >> cpu_data[] initializations in the future, we risk a situation where >> credit2 silently regresses to using a single massive runqueue. > > But such an ordering change is extremely unlikely, since the > CPU_STARTING notification specifically tells you that the given > CPU is now ready for normal use, which includes it having its > topology related data set up. I didn't mean so much that CPU_STARTING might change meaning, but that someone looking only at schedule.c might think that it would make sense to call alloc_pdata() somewhere else, before cpu_data[] had been populated. Even if they look at init_pcpu() in credit2, they're unlikely to know that cpu_to_socket() isn't valid until after boot_secondary() has happened; and if they try it and boot it, everything will seem to work perfectly for credit2 -- except that there will be a single global runqueue. If you, Dario and I don't happen to catch it -- or don't happen to remember the exact details of the constraints -- nobody may notice until a year later. This is the point of having ASSERTs -- so that we don't have to worry about remembering and catching all these crazy constraints. -George