From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Proposed new "memory capacity claim" hypercall/feature Date: Thu, 08 Nov 2012 10:50:03 +0000 Message-ID: References: <509B8DC102000078000A72BA@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <509B8DC102000078000A72BA@nat28.tlf.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: TimDeegan , Olaf Hering , IanCampbell , Konrad Rzeszutek Wilk , George Dunlap , Ian Jackson , George Shuklin , Dan Magenheimer , xen-devel@lists.xen.org, DarioFaggioli , Kurt Hackel , Zhigang Wang List-Id: xen-devel@lists.xenproject.org On 08/11/2012 09:47, "Jan Beulich" wrote: >> Ah, then I am out of date on how Linux services softirqs and preemption? Can >> softirqs/preemption occur any time, even in kernel mode, so long as no locks >> are held? >> >> I thought softirq-type work only happened during event servicing, only if >> the event servicing had interrupted user context (ie, would not happen if >> started from within kernel mode). So the restart of the hypercall trap >> instruction would be an opportunity to service hardirqs, but not softirqs or >> scheduler... > > No, irq_exit() can invoke softirqs, provided this isn't a nested IRQ > (soft as well as hard) or softirqs weren't disabled in the interrupted > context. Ah, okay. In fact maybe that's always been the case and I have misremembered this detail, since condition for softirq entry in Xen has always been more strict than this. > The only thing that indeed is - on non-preemptible kernels - done > only on exit to user mode is the eventual entering of the scheduler. That alone may still be an argument for restricting the batch size from the toolstack? -- Keir