All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Justin Chen <justinpopo6@gmail.com>
Cc: <linux-mips@linux-mips.org>,
	<bcm-kernel-feedback-list@broadcom.com>,
	Justin Chen <justin.chen@broadcom.com>
Subject: Re: [RFC] MIPS: Add cacheinfo support
Date: Mon, 12 Dec 2016 16:19:41 -0800	[thread overview]
Message-ID: <584F3E9D.9030501@imgtec.com> (raw)
In-Reply-To: <6981ff1e-685e-2df7-4b6e-c67c3aa735e7@gmail.com>

On 12/12/2016 01:57 PM, Florian Fainelli wrote:
> OK, how would you want that to be represented? Should we try to "link"
> with the leaf we are coherent with? For instance, if the L1D cache is
> coherent with the L2, we have something like this:
>
> # Assuming this is L1D cache:
> /sys/devices/system/cpu/cpu0/cache/index0
> ls -1
> coherency_line_size
> level
> number_of_sets
> physical_line_partition
> power/
> shared_cpu_list
> shared_cpu_map
> size
> type
> uevent
> ways_of_associativity
>
> We add a new symbolic link, e.g:
>
> coherent_with -> ../index1
>
> that indicates that this cache is coherent with the cache pointed at by
> directory index1.
>
> Thanks!
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)

So, the standard MIPS L1D could be "flush_required", 
"invalidate_required" and "coherent_to_level", L1I could be 
"invalidate_required" and a fully coherent MIPS I6400 L1D could be just 
"coherent_to_level" (no flush/invalidate required).

The reason why I don't like symlink here because it is more precise 
information and it immediately pulls the question "do we need to have 
horizontal links like CPU0 L1D is coherent with CPU1 L1D?" or "do we 
need to have a horizontal link like CPU0 L1D is coherent with CPU1 L1I?" 
or "do we have a MEMORY object?" or "what if coherency is not 
bidirectional (L1D snoops L2 but not vise versa). And you should 
maintain that links in case of CPU goes on/offline. And pulling info 
from that link net is nontrivial in user level, especially if "lshw" 
works in parallel with CPUx going offline.

But what you need is actually the answer on that 3 questions (see flags 
above). At least I don't see a reason for more complicated cache level 
relationship. Even the case BIG-LITTLE still is covered by flags.

- Leonid.

WARNING: multiple messages have this Message-ID (diff)
From: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
To: Florian Fainelli <f.fainelli@gmail.com>,
	Justin Chen <justinpopo6@gmail.com>
Cc: linux-mips@linux-mips.org, bcm-kernel-feedback-list@broadcom.com,
	Justin Chen <justin.chen@broadcom.com>
Subject: Re: [RFC] MIPS: Add cacheinfo support
Date: Mon, 12 Dec 2016 16:19:41 -0800	[thread overview]
Message-ID: <584F3E9D.9030501@imgtec.com> (raw)
Message-ID: <20161213001941.BsnmPrbmd1OXlw1gAi3RVcuAlshlz6OEQHve0cktUy4@z> (raw)
In-Reply-To: <6981ff1e-685e-2df7-4b6e-c67c3aa735e7@gmail.com>

On 12/12/2016 01:57 PM, Florian Fainelli wrote:
> OK, how would you want that to be represented? Should we try to "link"
> with the leaf we are coherent with? For instance, if the L1D cache is
> coherent with the L2, we have something like this:
>
> # Assuming this is L1D cache:
> /sys/devices/system/cpu/cpu0/cache/index0
> ls -1
> coherency_line_size
> level
> number_of_sets
> physical_line_partition
> power/
> shared_cpu_list
> shared_cpu_map
> size
> type
> uevent
> ways_of_associativity
>
> We add a new symbolic link, e.g:
>
> coherent_with -> ../index1
>
> that indicates that this cache is coherent with the cache pointed at by
> directory index1.
>
> Thanks!
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)

So, the standard MIPS L1D could be "flush_required", 
"invalidate_required" and "coherent_to_level", L1I could be 
"invalidate_required" and a fully coherent MIPS I6400 L1D could be just 
"coherent_to_level" (no flush/invalidate required).

The reason why I don't like symlink here because it is more precise 
information and it immediately pulls the question "do we need to have 
horizontal links like CPU0 L1D is coherent with CPU1 L1D?" or "do we 
need to have a horizontal link like CPU0 L1D is coherent with CPU1 L1I?" 
or "do we have a MEMORY object?" or "what if coherency is not 
bidirectional (L1D snoops L2 but not vise versa). And you should 
maintain that links in case of CPU goes on/offline. And pulling info 
from that link net is nontrivial in user level, especially if "lshw" 
works in parallel with CPUx going offline.

But what you need is actually the answer on that 3 questions (see flags 
above). At least I don't see a reason for more complicated cache level 
relationship. Even the case BIG-LITTLE still is covered by flags.

- Leonid.

  reply	other threads:[~2016-12-13  0:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-08  1:16 [RFC] MIPS: Add cacheinfo support justinpopo6
2016-12-08 23:26 ` Leonid Yegoshin
2016-12-08 23:26   ` Leonid Yegoshin
2016-12-09  0:28   ` Justin Chen
2016-12-09  1:01     ` Leonid Yegoshin
2016-12-09  1:01       ` Leonid Yegoshin
2016-12-12 18:24       ` Florian Fainelli
2016-12-12 20:45         ` Leonid Yegoshin
2016-12-12 20:45           ` Leonid Yegoshin
2016-12-12 21:57           ` Florian Fainelli
2016-12-13  0:19             ` Leonid Yegoshin [this message]
2016-12-13  0:19               ` Leonid Yegoshin
2016-12-13 11:09               ` Maciej W. Rozycki
2016-12-13 11:09                 ` Maciej W. Rozycki
2016-12-13 19:18                 ` Leonid Yegoshin
2016-12-13 19:18                   ` Leonid Yegoshin
2016-12-13 20:01                   ` Justin Chen
2016-12-13 20:05                     ` Florian Fainelli
2016-12-13 20:15                       ` Leonid Yegoshin
2016-12-13 20:15                         ` Leonid Yegoshin
2016-12-13 21:53           ` Ralf Baechle
2016-12-13 21:48       ` Ralf Baechle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=584F3E9D.9030501@imgtec.com \
    --to=leonid.yegoshin@imgtec.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=f.fainelli@gmail.com \
    --cc=justin.chen@broadcom.com \
    --cc=justinpopo6@gmail.com \
    --cc=linux-mips@linux-mips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.