On 12/13/2016 12:01 PM, Justin Chen wrote: > On Tue, Dec 13, 2016 at 11:18 AM, Leonid Yegoshin > <Leonid.Yegoshin@xxxxxxxxxx> wrote: >> On 12/13/2016 03:09 AM, Maciej W. Rozycki wrote: >>> >>> On Tue, 13 Dec 2016, Leonid Yegoshin wrote: >>> >>>> Well, I prefer the collection of 3 flags: >>>> >>>> flush_required - or flush to next level is required to force >>>> coherency >>>> between this level and next after update of this level >>>> invalidate_required - or invalidate is required to force coherency >>>> between >>>> this level and next after update of next level >>>> coherent_to_level - object is coherent with this level (only one >>>> domain of >>>> coherency on this level is assumed) >>> >>> A "flush" has always been an ambiguous term -- meaning anything from >>> "write-back", through "write-back+invalidate" to "invalidate". What is >>> "flush" is supposed to exactly mean here? If specifically any of the two >>> formers (the latter is obviously the other flag), then I suggest using the >>> respective name, or otherwise if it is meant to be generic "do what is >>> needed", then perhaps "synchronize" will work, like with the name of the >>> SYNCI instruction? >>> >> Well, I am not expert in choosing names, you know. I just would like to make >> a distinguishing between "transfer data from this level to next one" - any >> way - writeback or write-back-invalidate, and "clear data in this level to >> be pulled on demand from next level". >> >> This is an information purpose as Florian described, so details can be >> skipped. The only useful info here - some efforts are needed after event >> (see above) and that efforts are not cheap from performance point of view. >> >> If we put here details then it is a long way because we need a lot of >> details, see my original post. However, I would like to differ "flush" and >> "invalidate" because it is triggered by different kind of event (from >> upstream or from downstream). >> >> - Leonid. > I can add in the flags mentioned by Leonid. However, I would suggest > these flags be added in as a separate patch series as it will require > modifications to the cacheinfo code to propagate the information to > the sysfs. > > Would it be ok to accept this patch series as is while I work with the > cacheinfo maintainers to include these new flags? Seems entirely reasonable to me. You may want to make a new patch submission without "RFC", just to make it clear that this is a patch ready for review/acceptance. Thanks! -- Florian
