From: WANG Xuerui <i@xen0n.name>
To: Lulu Cheng <chenglulu@loongson.cn>,
gcc-patches@gcc.gnu.org, cmtice@google.com
Cc: xry111@xry111.site, xuchenghua@loongson.cn,
qijingwen <qijingwen@loongson.cn>
Subject: Re: [PATCH v3] LoongArch: Libvtv add loongarch support.
Date: Fri, 28 Oct 2022 17:38:03 +0800 [thread overview]
Message-ID: <319ad298-645f-79f0-a2c0-37b95a7e5f59@xen0n.name> (raw)
In-Reply-To: <20221028080146.1586483-1-chenglulu@loongson.cn>
Hi,
The code change seems good but a few grammatical nits.
Patch subject should be a verb phrase, something like "libvtv: add
LoongArch support" could be better.
On 2022/10/28 16:01, Lulu Cheng wrote:
> After several considerations, I decided to set VTV_PAGE_SIZE to 16KB under loongarch64.
>
>
> v1 - > v2:
>
> 1. When the macro __loongarch_lp64 is defined, the VTV_PAGE_SIZE is set to 64K.
> 2. In the vtv_malloc.cc file __vtv_malloc_init function, it does not check
> whether VTV_PAGE_SIZE is equal to the system page size, if the macro
> __loongarch_lp64 is defined.
>
> v2 -> v3:
>
> Set VTV_PAGE_SIZE to 16KB under loongarch64.
>
>
>
> All regression tests of libvtv passed.
>
> === libvtv Summary ===
>
> # of expected passes 176
>
> -----------------------------------------
Are the monologue and changelog supposed to be a part of the actual
commit? If not, conventionally they should be placed *after* the "---"
line separating the commit message and diffstat/patch content.
>
> The loongarch64 kernel supports 4KB,16KB, or 64KB pages,
> but only 16k pages are currently supported in this code.
This sentence feels a little bit unnatural. I suggest just "The
LoongArch specification permits page sizes of 4KiB, 16KiB and 64KiB, but
only 16KiB pages are supported for now".
>
> Co-Authored-By: qijingwen <qijingwen@loongson.cn>
>
> include/ChangeLog:
>
> * vtv-change-permission.h (defined):
> (VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KB under loongarch64.
"for loongarch64" feels more natural.
>
> libvtv/ChangeLog:
>
> * configure.tgt: Add loongarch support.
> ---
> include/vtv-change-permission.h | 5 +++++
> libvtv/configure.tgt | 3 +++
> 2 files changed, 8 insertions(+)
>
> diff --git a/include/vtv-change-permission.h b/include/vtv-change-permission.h
> index 70bdad92bca..f61d8b68ef6 100644
> --- a/include/vtv-change-permission.h
> +++ b/include/vtv-change-permission.h
> @@ -48,6 +48,11 @@ extern void __VLTChangePermission (int);
> #else
> #if defined(__sun__) && defined(__svr4__) && defined(__sparc__)
> #define VTV_PAGE_SIZE 8192
> +#elif defined(__loongarch_lp64)
> +/* The page size can be configured to 4, 16, or 64KB configuring the kernel.
"The page size is configurable by the kernel to be 4, 16 or 64 KiB."
> + However, only 16KB pages are supported here. Please modify this macro if you
> + want to support other page sizes. */
Are we actually encouraging the users to modify the sources themselves
if they decide to run with non-16KiB page size? This might not even be
feasible, as you're essentially telling them to recompile part of the
toolchain, which they may not want to / cannot do.
I think the message you want to convey here is for them to voice their
need upstream so we can then discuss. In that case, the 2 sentences here
could be:
"For now, only the default page size of 16KiB is supported. If you have
a need for other page sizes, please get in touch."
Although I'm not sure if the vague "get in touch" wording is
appropriate. What do others think?
> +#define VTV_PAGE_SIZE 16384
> #else
> #define VTV_PAGE_SIZE 4096
> #endif
> diff --git a/libvtv/configure.tgt b/libvtv/configure.tgt
> index aa2a3f675b8..6cdd1e97ab1 100644
> --- a/libvtv/configure.tgt
> +++ b/libvtv/configure.tgt
> @@ -50,6 +50,9 @@ case "${target}" in
> ;;
> x86_64-*-darwin[1]* | i?86-*-darwin[1]*)
> ;;
> + loongarch*-*-linux*)
> + VTV_SUPPORTED=yes
> + ;;
> *)
> ;;
> esac
next prev parent reply other threads:[~2022-10-28 9:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 8:01 Lulu Cheng
2022-10-28 9:38 ` WANG Xuerui [this message]
2022-10-28 14:24 ` chenglulu
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=319ad298-645f-79f0-a2c0-37b95a7e5f59@xen0n.name \
--to=i@xen0n.name \
--cc=chenglulu@loongson.cn \
--cc=cmtice@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=qijingwen@loongson.cn \
--cc=xry111@xry111.site \
--cc=xuchenghua@loongson.cn \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).