On Wed, 2016-03-16 at 10:37 -0400, Meng Xu wrote: > On Wed, Mar 16, 2016 at 4:23 AM, Dario Faggioli > wrote: > >  > > I continue to think that it could be useful to have this logged, > > but > > I'm leaning toward just killing it for now (and maybe finding > > another > > way to check and warn about the same thing or one of the effects it > > produces, later). > > > > Meng, what do you think? > I'm thinking about if it may not be worthwhile *for now only* to > provide such information with so much effort and the danger of > introducing more serious issues. > Yeah, exactly what I was also saying. > Right, race condition occurs on the global variable and I believe we > don't want to encounter this race condition. > So let's just not use the global variable. > Well, it would just affect the logging itself. But then, why clobber the (clarity of the) code for introducing proper per-domain logging, and ending up with something that may not actually be per-domain.. that's how I was thinking at it. > We should definitely put a large warning in the wiki for the RTDS > scheduler about the parameter settings. Incorrect setting should > never > crash system but may lead to poor real-time performance users want. > For example, one way of dealing with this would be to allow the user/sysadmin to set what the minimum budget and period they want to be able to use would be, by means of SYSCTLs. We kind of like have a static and a dynamic limit. The former, hardcoded in Xen, to something that we know is unreasonable on any hardware platform available at that time. The latter, we can set to a rather conservative high value by default, but let users that wants to lower it, do that... and there is where we can print all the warnings we want! I'm just tossing this out there, though, and this is certainly something that can come as future work. Regards, Dario -- <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)