On Wednesday, 29 March 2017 at 5:47 PM, Martin Kletzander wrote:
On Wed, Mar 29, 2017 at 05:31:42PM +0800, Eli Qiao wrote:
>
>
> --
> Best regards
> Eli
>
> 天涯无处不重逢
> a leaf duckweed belongs to the sea, where not to meet in life
>
> Sent with Sparrow (
http://www.sparrowmailapp.com/?sig)
OK, please do something with your client. Having the footer here on top
for every reply is *sooooo* bothersome when you are replying inline
(that part is fine).
Sorry, I removed footer, better now?
> On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:
>
> > On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:
> > >
> > >
> > > --
> > > Best regards
> > > Eli
> > >
> > > 天涯无处不重逢
> > > a leaf duckweed belongs to the sea, where not to meet in life
> > >
> > > Sent with Sparrow (
http://www.sparrowmailapp.com/?sig)
> > >
> > >
> > > On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:
> > >
> > > > On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:
> > > > > hi Martin
> > > > >
> > > > > (cc libvir-list)
> > > > >
> > > > > I am a little confused about cat support.
> > > > >
> > > > > I am currently rebasing my code on top of pre-cat branch from
your private github repo, today when I check it you have removed it and create a cat
branch and there are some related code pushed[1], can I know what ’s your plan for my
patch set for CAT support ? should I continue my rebasing work? your though?
> > > >
> > > > So we can work together on that. Since the rework of the sysfs
> > > > functions, some patches are easier to write from scratch then
rewrite,
> > > > but I'm now just trying to setup the test suite, so that we have
> > > > something to test on, at least some of the code. So where are you in
> > > > the rebase right now? Do you think anything from the virsysfs.c code
> > > > could be enhanced?
> > > >
> > >
> > >
> > >
> > >
> > >
> > > Not so fast, only the first patch [1], I found that nodeinfo.c is removed
:(
> > >
> > > I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint
to virsysfs.c
> > >
> > > thought ?
> >
> > Yeah, we should wrap around /sys/fs/resctrl as we do with
> > /sys/devices/system so that it can be easily tested.
> >
>
> Sure, working on it, and done, will push it for review.
>
> Also I will push some fake data for resctrl testing..
>
>
> >
> > Also I got another idea about keeping the resource info. There is no
> > need for any global data to be stored as you are re-reading almost all
> > of it. The only info that stays the same is caches (that is already
> > saved in capabilities) and what caches are available for resource
> > control (that will be there as well). So I don't think we need yet
> > another global data storage.
> >
>
>
> Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) when we
create/destroy instance?
> also, for get free cache ?
>
You have to update that for every request anyway, so what's the point of
keeping the data when they immediately become old?
I was thought that may reduce the time costing, not all of the content be
refreshed, anyway, I will try to avoid global files in my later version.
LoL lots of rebasing :(
Thanks for your suggestion.
> This is what I did in my early PoC, that will much easier… but please keep in mind
that only one thread can read/write to /sys/fs/resctrl at one time.
Yeah, that's what we have locks for.
> the neck bottle is /sys/fs/resctrl
Sure you mean bottleneck, right? :)
yes, bottleneck,