[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
>From: Keir Fraser [mailto:keir@xxxxxxxxxxxxx] >Sent: 2007年8月30日 17:31 > >On 30/8/07 07:41, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote: > >> a) Current approach is simple to let Dom0 conduct frequency >> change. That should be OK in the start, but at the same time we >> should also consider the on-demand governor within Xen itself. >> Xen can always get first-hand data about domain status, while >> dom0 (either user-level or in-kernel) can't achieve in time. Fine- >> grained frequency change is more likely to be achieved within >> Xen directly. > >Personally I'm a fan of doing it in dom0 userspace, although doing it >within >Xen can also be argued for. Doing it in dom0 kernel doesn't seem very >attractive apart from the obvious pragmatic advantage that all the code is >already in the Linux kernel. :-) Sure, some experiment can be done later to compare dom0 userspace and in-xen governor. Agree that in-kernel dom0 approach is not charming because anyway it needs help from either user-level or xen for global view. Actually finally we may take both. Xen takes simple heuristic policy with user-level governor to adjust with more complex and flexible policies based on domain behaviors. :-) > >If we're doing it in the Linux kernel, I don't see much point in hacking up >the defunct powernow (or equivalent Intel) code. Why not fix the generic >acpi-cpufreq.c? That is supposed to work on any modern CPU. I'm not >sure the >2.6.18 version is new enough, but I'd rather see a backported and fixed >version of that file, rather than bother to maintain modified versions of >obsolete source files. > Yep. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |