From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Dec 2016 21:16:09 +0100 (CET) Received: from mailapp01.imgtec.com ([195.59.15.196]:37325 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993072AbcLMUQCtIVZD (ORCPT ); Tue, 13 Dec 2016 21:16:02 +0100 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Forcepoint Email with ESMTPS id AAFE020E52496; Tue, 13 Dec 2016 20:15:52 +0000 (GMT) Received: from HHMAIL-X.hh.imgtec.org (10.100.10.113) by hhmail02.hh.imgtec.org (10.100.10.20) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 13 Dec 2016 20:15:56 +0000 Received: from BAMAIL02.ba.imgtec.org (10.20.40.28) by HHMAIL-X.hh.imgtec.org (10.100.10.113) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 13 Dec 2016 20:15:55 +0000 Received: from [10.20.2.61] (10.20.2.61) by bamail02.ba.imgtec.org (10.20.40.28) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 13 Dec 2016 12:15:53 -0800 Message-ID: <585056F9.7010101@imgtec.com> Date: Tue, 13 Dec 2016 12:15:53 -0800 From: Leonid Yegoshin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Florian Fainelli , Justin Chen CC: "Maciej W. Rozycki" , , , Justin Chen Subject: Re: [RFC] MIPS: Add cacheinfo support References: <20161208011626.20885-1-justinpopo6@gmail.com> <5849EC43.2070802@imgtec.com> <584A0281.3040505@imgtec.com> <3004fca6-3688-65bb-7c86-248603482088@gmail.com> <584F0C71.5010004@imgtec.com> <6981ff1e-685e-2df7-4b6e-c67c3aa735e7@gmail.com> <584F3E9D.9030501@imgtec.com> <58504983.2050608@imgtec.com> <31824f14-e8b0-2f14-2ade-1c30e6e3cce5@gmail.com> In-Reply-To: <31824f14-e8b0-2f14-2ade-1c30e6e3cce5@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.20.2.61] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 56038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Leonid.Yegoshin@imgtec.com Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On 12/13/2016 12:05 PM, Florian Fainelli wrote: > On 12/13/2016 12:01 PM, Justin Chen wrote: >> On Tue, Dec 13, 2016 at 11:18 AM, Leonid Yegoshin >> 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! I agree. - Leonid. From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailapp01.imgtec.com ([195.59.15.196]:37325 "EHLO mailapp01.imgtec.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23993072AbcLMUQCtIVZD (ORCPT ); Tue, 13 Dec 2016 21:16:02 +0100 Message-ID: <585056F9.7010101@imgtec.com> Date: Tue, 13 Dec 2016 12:15:53 -0800 From: Leonid Yegoshin MIME-Version: 1.0 Subject: Re: [RFC] MIPS: Add cacheinfo support References: <20161208011626.20885-1-justinpopo6@gmail.com> <5849EC43.2070802@imgtec.com> <584A0281.3040505@imgtec.com> <3004fca6-3688-65bb-7c86-248603482088@gmail.com> <584F0C71.5010004@imgtec.com> <6981ff1e-685e-2df7-4b6e-c67c3aa735e7@gmail.com> <584F3E9D.9030501@imgtec.com> <58504983.2050608@imgtec.com> <31824f14-e8b0-2f14-2ade-1c30e6e3cce5@gmail.com> In-Reply-To: <31824f14-e8b0-2f14-2ade-1c30e6e3cce5@gmail.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Florian Fainelli , Justin Chen Cc: "Maciej W. Rozycki" , linux-mips@linux-mips.org, bcm-kernel-feedback-list@broadcom.com, Justin Chen Message-ID: <20161213201553.XJFHgXTZLy9keUS3jQXVVamD3GtAvVFVH7s37F3u-vY@z> On 12/13/2016 12:05 PM, Florian Fainelli wrote: > On 12/13/2016 12:01 PM, Justin Chen wrote: >> On Tue, Dec 13, 2016 at 11:18 AM, Leonid Yegoshin >> 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! I agree. - Leonid.