Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 20 Oct 2021 18:01:31 -0700 (PDT)
From:   Paul Walmsley <paul.walmsley@sifive.com>
To:     Darius Rad <darius@bluespec.com>
cc:     Greentime Hu <greentime.hu@sifive.com>,
        linux-riscv <linux-riscv@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Albert Ou <aou@eecs.berkeley.edu>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Vincent Chen <vincent.chen@sifive.com>
Subject: Re: [RFC PATCH v8 09/21] riscv: Add task switch support for vector
In-Reply-To: <YVxZspMO7rAvtMBS@bruce.bluespec.com>
Message-ID: <3c9797f6-2fd3-5530-ba34-6e4c4deec984@sifive.com>
References: <cover.1631121222.git.greentime.hu@sifive.com> <0e65c165e3d54a38cbba01603f325dca727274de.1631121222.git.greentime.hu@sifive.com> <c81267bc-4c91-3978-8c1f-78925c46c78b@bluespec.com> <CAHCEehJ1uuSFqFWreS1kh+fR5GFfnEycdLMe+4FHXpFsHrRUvA@mail.gmail.com>
 <YVRp5uWFGQrwBpgf@bruce.bluespec.com> <CAHCEeh+dA9243=PwNtYvyU1Myu_E8YO2g4UNACxRogQ=6UavLQ@mail.gmail.com> <YVxZspMO7rAvtMBS@bruce.bluespec.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="8323329-1340494379-1634778091=:93269"
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1340494379-1634778091=:93269
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hello Darius,

On Tue, 5 Oct 2021, Darius Rad wrote:

> On Mon, Oct 04, 2021 at 08:36:30PM +0800, Greentime Hu wrote:
> > Darius Rad <darius@bluespec.com> =E6=96=BC 2021=E5=B9=B49=E6=9C=8829=E6=
=97=A5 =E9=80=B1=E4=B8=89 =E4=B8=8B=E5=8D=889:28=E5=AF=AB=E9=81=93=EF=BC=9A
> > >
> > > On Tue, Sep 28, 2021 at 10:56:52PM +0800, Greentime Hu wrote:
> > > > Darius Rad <darius@bluespec.com> =E6=96=BC 2021=E5=B9=B49=E6=9C=881=
3=E6=97=A5 =E9=80=B1=E4=B8=80 =E4=B8=8B=E5=8D=888:21=E5=AF=AB=E9=81=93=EF=
=BC=9A
> > > > >
> > > > > On 9/8/21 1:45 PM, Greentime Hu wrote:
> > > > > > This patch adds task switch support for vector. It supports par=
tial lazy
> > > > > > save and restore mechanism. It also supports all lengths of vle=
n.

[ ... ]

> > > > > So this will unconditionally enable vector instructions, and allo=
cate
> > > > > memory for vector state, for all processes, regardless of whether=
 vector
> > > > > instructions are used?
> > > >
> > > > Yes, it will enable vector if has_vector() is true. The reason that=
 we
> > > > choose to enable and allocate memory for user space program is beca=
use
> > > > we also implement some common functions in the glibc such as memcpy
> > > > vector version and it is called very often by every process. So tha=
t
> > > > we assume if the user program is running in a CPU with vector ISA
> > > > would like to use vector by default. If we disable it by default an=
d
> > > > make it trigger the illegal instruction, that might be a burden sin=
ce
> > > > almost every process will use vector glibc memcpy or something like
> > > > that.
> > >
> > > Do you have any evidence to support the assertion that almost every p=
rocess
> > > would use vector operations?  One could easily argue that the convers=
e is
> > > true: no existing software uses the vector extension now, so most lik=
ely a
> > > process will not be using it.
> >=20
> > Glibc ustreaming is just starting so you didn't see software using the=
=20
> > vector extension now and this patchset is testing based on those=20
> > optimized glibc too. Vincent Chen is working on the glibc vector=20
> > support upstreaming and we will also upstream the vector version glibc=
=20
> > memcpy, memcmp, memchr, memmove, memset, strcmp, strlen. Then we will=
=20
> > see platform with vector support can use vector version mem* and str*=
=20
> > functions automatically based on ifunc and platform without vector=20
> > will use the original one automatically. These could be done to select=
=20
> > the correct optimized glibc functions by ifunc mechanism.

In your reply, I noticed that you didn't address Greentime's response=20
here.  But this looks like the key issue.  If common library functions are=
=20
vector-accelerated, wouldn't it make sense that almost every process would=
=20
wind up using vector instructions?  And thus there wouldn't be much point=
=20
to skipping the vector context memory allocation?


- Paul
--8323329-1340494379-1634778091=:93269--