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? -Justin
