From: Ralf Baechle <ralf@linux-mips.org>
To: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
Cc: Justin Chen <justinpopo6@gmail.com>,
linux-mips@linux-mips.org, bcm-kernel-feedback-list@broadcom.com,
Florian Fainelli <f.fainelli@gmail.com>,
Justin Chen <justin.chen@broadcom.com>
Subject: Re: [RFC] MIPS: Add cacheinfo support
Date: Tue, 13 Dec 2016 22:48:09 +0100 [thread overview]
Message-ID: <20161213214809.GA14262@linux-mips.org> (raw)
In-Reply-To: <584A0281.3040505@imgtec.com>
On Thu, Dec 08, 2016 at 05:01:53PM -0800, Leonid Yegoshin wrote:
> CACHE instruction is not available in user space, only SYNCI on MIPS R2+ for
> trampoline.
> Any operation with CACHE requires a syscall.
Even worse, some older CPUs allow the execution of certain CACHE operations
from user space. This is a feature which can be disabled by kernel.
> As for SYNCI (trampoline from L1D->L1I) the following information in user
> space is needed:
>
> 1. L1 line size (available via RDHWR $x, $1). It is available now
> directly from CPU, but may be better to supply from kernel because some
> cores has no that.
>
> 2. The flag that L1I is NOT coherent with L1D and SYNCI is needed and
> available
>
> The knowledge about L1/L2 sizes is not needed for regular application...
> well, if application wants to get advantage of cache sizes, well, in this
> case it can be supplied.
>
> But it is unreliable because app may be rescheduled into different kind of
> core which has a different L1 size (in heterogeneous system, BTW). It can be
> fixed by setting affinity, of course (not sure - can it be reliably done in
> BIG/LITTLE approach). But that requires in application the knowledge and
> understanding of system CPU structure... well why we can allow all that
> stuff besides information purpose? It corrupts the all efforts and
> optimization in kernel about performance and powersaving.
Also let's not forget about CPUs like Octeons which have CPUs that don't
quite fit in the usual scheme of doing things.
Ralf
prev parent reply other threads:[~2016-12-13 21:48 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
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 [this message]
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=20161213214809.GA14262@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=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.