public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

  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).