<div>
                    <br>
                </div>
                <div></div>
                 
                <p style="color: #A0A0A8;">On Wednesday, 29 March 2017 at 5:47 PM, Martin Kletzander wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>On Wed, Mar 29, 2017 at 05:31:42PM +0800, Eli Qiao wrote:</div><blockquote type="cite"><div><div><br></div><div><br></div><div>--</div><div>Best regards</div><div>Eli</div><div><br></div><div>天涯无处不重逢</div><div>a leaf duckweed belongs to the sea, where not to meet in life</div><div><br></div><div>Sent with Sparrow (<a href="http://www.sparrowmailapp.com/?sig">http://www.sparrowmailapp.com/?sig</a>)</div></div></blockquote><div><br></div><div>OK, please do something with your client.  Having the footer here on top</div><div>for every reply is *sooooo* bothersome when you are replying inline</div><div>(that part is fine).</div><div><br></div></div></div></span></blockquote><div>Sorry, I removed footer, better now?</div><div> </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><blockquote type="cite"><div><div>On Wednesday, 29 March 2017 at 5:19 PM, Martin Kletzander wrote:</div><div><br></div><blockquote type="cite"><div><div>On Wed, Mar 29, 2017 at 04:22:16PM +0800, Eli Qiao wrote:</div><blockquote type="cite"><div><div><br></div><div><br></div><div>--</div><div>Best regards</div><div>Eli</div><div><br></div><div>天涯无处不重逢</div><div>a leaf duckweed belongs to the sea, where not to meet in life</div><div><br></div><div>Sent with Sparrow (<a href="http://www.sparrowmailapp.com/?sig">http://www.sparrowmailapp.com/?sig</a>)</div><div><br></div><div><br></div><div>On Wednesday, 29 March 2017 at 3:45 PM, Martin Kletzander wrote:</div><div><br></div><blockquote type="cite"><div><div>On Tue, Mar 28, 2017 at 03:22:34PM +0800, Eli Qiao wrote:</div><blockquote type="cite"><div><div>hi Martin</div><div><br></div><div>(cc libvir-list)</div><div><br></div><div>I am a little confused about cat support.</div><div><br></div><div>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?</div></div></blockquote><div><br></div><div>So we can work together on that. Since the rework of the sysfs</div><div>functions, some patches are easier to write from scratch then rewrite,</div><div>but I'm now just trying to setup the test suite, so that we have</div><div>something to test on, at least some of the code. So where are you in</div><div>the rebase right now? Do you think anything from the virsysfs.c code</div><div>could be enhanced?</div></div></blockquote><div><br></div><div><br></div><div><br></div><div><br></div><div>Not so fast, only the first patch [1], I found that nodeinfo.c is removed :(</div><div><br></div><div>I think we need to extend virResCtrlGetInfoStr and virResCtrlGetInfoUint to virsysfs.c</div><div><br></div><div>thought ?</div></div></blockquote><div><br></div><div>Yeah, we should wrap around /sys/fs/resctrl as we do with</div><div>/sys/devices/system so that it can be easily tested.</div></div></blockquote><div>Sure, working on it, and done, will push it for review.</div><div><br></div><div>Also I will push some fake data for resctrl testing..</div><div><br></div><div><br></div><blockquote type="cite"><div><div><br></div><div>Also I got another idea about keeping the resource info. There is no</div><div>need for any global data to be stored as you are re-reading almost all</div><div>of it. The only info that stays the same is caches (that is already</div><div>saved in capabilities) and what caches are available for resource</div><div>control (that will be there as well). So I don't think we need yet</div><div>another global data storage.</div></div></blockquote><div><br></div><div>Do you mean, we re-create all struct (reading them from /sys/fs/resctrl) when we create/destroy instance?</div><div>also, for get free cache ?</div></div></blockquote><div><br></div><div>You have to update that for every request anyway, so what's the point of</div><div>keeping the data when they immediately become old?</div><div><br></div></div></div></span></blockquote><div>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. </div><div><br></div><div>LoL lots of rebasing  :( </div><div><br></div><div>Thanks for your suggestion.</div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><div><div></div><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>Yeah, that's what we have locks for.</div><div><br></div><blockquote type="cite"><div>the neck bottle is /sys/fs/resctrl</div></blockquote><div><br></div><div>Sure you mean bottleneck, right? :)</div></div></div></span></blockquote><div>yes, bottleneck, </div>
                 
                <div>
                    <br>
                </div>