* Sanidhya Kashyap (sanidhya.ii...@gmail.com) wrote:
> >
> > 1) Do you have some examples of output?
> > Can you see hot areas in the kernel or something else?
> >
>
> I looked at it sometimes back. I will try to provide some images (as
> suggested by you earlier) to see any consistently used areas.
>
> > 2) 'frequency' is probably the wrong name for the parameter you have; since
> > the parameter is actually the delay between epochs, where as frequency
> > would imply the number of epochs/second.
> >
>
> will surely change it to period. It is pointed out by Eric too.
>
> > 3) The change to runstates is interesting; up until now 'runstate' is really
> > mostly about the state of the CPU, but by adding migration/dumping to the
> > states you're trying to convey more in that single state variable; I'm not
> > quite sure if this is the right thing to do or not.
> >
>
> Is there any alternative that can allow us to execute only one of the
> processes - either migration or bitmap dump. One very basic approach
> that I have thought is about using a global variable but don't know
> whether that is a good option or not.
>
> Any other alternative is welcomed.
I think a global variable is the right thing; something like 'dirty_bitmap_user'
being an enum between none, migration, dumping would make sense to me.
While adding global variables ia a bad thing, since the dirty bitmap already is
global all you're doing really is adding an extra bit of state to it.
If you have something like
char *dirty_bitmap_user_as_string()
then your test in your qml code would look something like:
if (dirty_bitmap_user != dbu_none) {
error_report("Can't do dirty dumping since %s is in use",
dirty_bitmap_user_as_string());
}
and then if more things use it in the future the existing users don't
have to change.
Dave
>
> -----
>
> Sanidhya Kashyap
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
