Re: [Xen-devel] [PATCH v6 for Xen 4.7 1/4] xen: enable per-VCPU parameter settings for RTDS scheduler

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

On Tue, 2016-03-15 at 11:22 -0500, Chong Li wrote:
> On Mon, Mar 14, 2016 at 5:05 AM, Dario Faggioli
> <dario.faggioli@xxxxxxxxxx> wrote:
> > 
> > However, for this specific case, I was also considering that, and I
> > agree, if possible/not to difficult to implement, once per domain
> > would
> > indeed be better.
> > 
> It is easy to implement a global "warn_on_once".
> 
Sure.

> To implement a per-domain "warn_on_once", I may need a hash table
> (name it as "dom_warned"), and dom_warned[domid] returns true or
> false.
> I don't know if hash table is supported in Xen. Or do we have any
> list
> structure which is very good at searching?
> 
And all this just for having _this_ specific warning printed once per
domain.

No, I don't think it is worth... Or maybe it is, but I don't think it's
fair to ask you to do it. Or maybe, if you're up for doing it, then
you're free to, but I don't think it's fair to ask for it as
prerequisite for this patch. :-)

> Another way is to add a "bool" field in struct domain, but I don't
> think that would be a good design.
> 
Yeah, I like it even less. :-/

We said 'once' and then 'once per domain', but something I'd be fine
with (coupled with keeping G_WARNING) would be 'once per operation'.
Basically, if a domain has 128 vcpus, and an hypercall tries to set all
of them to period=100, budget=50, we just print the warning once. Then,
if after a while the sysadmin tries the same again, we again just log
once, etc.

Doing this seems much easier, as the 'warned' flag could just be a
local variable of the hypercall implementation. I'm quite sure that
would work if there is not any continuation/re-issueing mechanism in
the hypercall in question. BUT in our case there is, so things may be
more complicated... :-/

Had you thought about a solution like this already? If no, can you see
whether there is a nice and easy way to make something like what I just
described above to work in our case?

If we find nothing, we'll think at alternatives, including killing the
waning.

Thanks and Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel