[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Proposed new "memory capacity claim" hypercall/feature

>>> On 08.11.12 at 10:12, Keir Fraser <keir@xxxxxxx> wrote:
> On 08/11/2012 08:54, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> That may have mattered when ioctl-s were run with the big kernel
>> lock held, but even 2.6.18 didn't do that anymore (using the
>> .unlocked_ioctl field of struct file_operations), which means
>> that even softirqs will get serviced in Dom0 since the preempted
>> hypercall gets restarted via exiting to the guest (i.e. events get
>> delivered). Scheduling is what indeed wouldn't happen, but if
>> allocation latency can be brought down, 8M might turn out pretty
>> small a chunk size.
> 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

The only thing that indeed is - on non-preemptible kernels - done
only on exit to user mode is the eventual entering of the scheduler.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.