Didn''t get any answer to this one, yet: Is there a particular reason Jeremy''s sched_clock() variant isn''t being used in linux-2.6.18-hg? Specifically, are there any known downsides to that approach? Thanks, Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Noone''s bothered to backport it since what''s in the 2.6.18 tree works fine. Also I thought there were significant changes to Linux time handling after 2.6.18 -- would the approach even backport that easily? -- Keir On 13/12/07 09:59, "Jan Beulich" <jbeulich@novell.com> wrote:> Didn''t get any answer to this one, yet: > > Is there a particular reason Jeremy''s sched_clock() variant isn''t being > used in linux-2.6.18-hg? Specifically, are there any known downsides to > that approach? > > Thanks, Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 13.12.07 12:06 >>> >Noone''s bothered to backport it since what''s in the 2.6.18 tree works fine. > >Also I thought there were significant changes to Linux time handling after >2.6.18 -- would the approach even backport that easily?I''m not talking about the whole time handling, just the sched_clock() implementation taking stolen time into account. I have to admit that one of the reasons that I didn''t try doing this so far is the odd ''if (offset < 0)'' check in there - I would have expected that rather than doing this the xen_clocksource_read()/get_runstate_snapshot() pair would need to go in a loop checking that the time version didn''t change (and then a negative offset ought to be a bug). Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 13/12/07 11:28, "Jan Beulich" <jbeulich@novell.com> wrote:> I''m not talking about the whole time handling, just the sched_clock() > implementation taking stolen time into account. > > I have to admit that one of the reasons that I didn''t try doing this so far > is the odd ''if (offset < 0)'' check in there - I would have expected that > rather than doing this the xen_clocksource_read()/get_runstate_snapshot() > pair would need to go in a loop checking that the time version didn''t > change (and then a negative offset ought to be a bug).Oh, I see. I think the pv_ops sched_clock() implementation is fine. xen_clocksource_read()/get_runstate_snapshot() do their own version-checkign loops, and I don''t think there is really an accuracy issue in not pulling those checks into an outer loop. The ''offset < 0'' check is cheap and frankly, where time based on TSC is concerned, it''s a nice safety catch. I''d be happy to see that sched_clock() implementation ported into other trees. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel