From: Rich Felker <dalias@libc.org>
To: Alistair Francis <alistair23@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
Christian Brauner <christian@brauner.io>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Alistair Francis <alistair.francis@wdc.com>,
GNU C Library <libc-alpha@sourceware.org>,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Florian Weimer <fweimer@redhat.com>,
Palmer Dabbelt <palmer@sifive.com>,
macro@wdc.com, Zong Li <zongbox@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Al Viro <viro@zeniv.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable
Date: Thu, 25 Jul 2019 00:40:09 -0400 [thread overview]
Message-ID: <20190725044009.GJ1506@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAKmqyKOXJxJq5-ktLc=oY7ooNj6-X9PotHNM=-xG95iPCAAmjQ@mail.gmail.com>
On Wed, Jul 24, 2019 at 05:04:53PM -0700, Alistair Francis wrote:
> On Tue, Jul 23, 2019 at 1:45 AM Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, Jul 23, 2019 at 10:29 AM Christian Brauner <christian@brauner.io> wrote:
> > > On Tue, Jul 23, 2019 at 10:12:07AM +0200, Arnd Bergmann wrote:
> > > > On Tue, Jul 23, 2019 at 2:01 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
> > > > > The BSDs implemented wait6 as their common wait that does everything
> > > > > system call. It's large contribution is that wait6 will give both
> > > > > the rusage of the child that exited and it's children separately.
> > > >
> > > > Ah right, that was one more thing I forgot on my earlier list. If we end up
> > > > creating a new wait4()/waitid() replacement to replace the timeval
> > > > with __kernel_timespec, we may want that to return a wrusage instead
> > > > of rusage. Same for Christian's proposed pidfd_wait().
> > >
> > > So I'm in the middle of writing tests for pidfd_wait. And I'm currently
> > > using struct rusage. I would suggest sending out a first version using
> > > struct rusage and then you can point out what you would like see as a
> > > replacement. What do you think, Arnd?
> >
> > Sounds good to me, the debate over what rusage to use should not hold
> > up the review of the rest of that syscall.
>
> I'm unclear what the final decision is here. What is the solution are
> we going to have wait4() or add P_PROCESS_PGID to waitid()?
>
> As well as that what is the solution to current implementations? If we
> add wait4() then there isn't an issue (and I can drop this patch) but
> if we add P_PROCESS_PGID then we will need a way to handle kernels
> with waitid() but no P_PROCESS_PGID. Although my new plan is to only
> use the waitid syscall if we don't have waitpid or wait4 so it seems
> like this will only affect RV32 for the time being.
I would really like some indication which solution will be taken,
since it impacts choices that will need to be made in musl very soon.
My favorite outcome would be bringing back wait4 for rv32 (and
no-time32 archs in general) *and* adding P_PROCESS_PGID. In the short
term, just using wait4 would be the simplest and cleanest for us (same
as all other archs, no extra case to deal with), but in the long term
there may be value in having rusage that can represent more than 68
cpu-years spent by a process (seems plausible with large numbers of
cores).
Rich
next prev parent reply other threads:[~2019-07-25 4:40 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-17 0:08 [RFC v3 00/23] RISC-V glibc port for the 32-bit Alistair Francis
2019-07-17 0:08 ` [RFC v3 01/23] sysdeps/nanosleep: Use clock_nanosleep_time64 if avaliable Alistair Francis
2019-07-17 5:16 ` Florian Weimer
2019-07-19 17:25 ` Alistair Francis
2019-07-20 14:24 ` Stepan Golosunov
2019-07-22 21:14 ` Alistair Francis
2019-07-17 0:08 ` [RFC v3 02/23] sysdeps/gettimeofday: Use clock_gettime64 " Alistair Francis
2019-07-17 7:09 ` Florian Weimer
2019-07-20 3:20 ` Rich Felker
2019-07-25 20:54 ` Joseph Myers
2019-07-17 12:43 ` Lukasz Majewski
2019-07-17 12:48 ` Lukasz Majewski
2019-07-19 22:26 ` Alistair Francis
2019-07-17 0:08 ` [RFC v3 03/23] sysdeps/wait: Use waitid " Alistair Francis
2019-07-17 5:31 ` Florian Weimer
2019-07-19 17:49 ` Alistair Francis
2019-07-22 15:58 ` Florian Weimer
2019-07-22 21:02 ` Alistair Francis
2019-07-21 4:03 ` Rich Felker
2019-07-21 4:20 ` Rich Felker
2019-07-21 11:59 ` Eric W. Biederman
2019-07-21 22:59 ` Rich Felker
2019-07-21 7:57 ` Arnd Bergmann
2019-07-21 12:15 ` Eric W. Biederman
2019-07-21 12:28 ` Christian Brauner
2019-07-21 14:30 ` Arnd Bergmann
2019-07-21 15:45 ` Eric W. Biederman
2019-07-21 17:05 ` Arnd Bergmann
2019-07-21 17:16 ` Linus Torvalds
2019-07-21 21:40 ` Eric W. Biederman
2019-07-21 23:23 ` Rich Felker
2019-07-23 0:00 ` Eric W. Biederman
2019-07-23 8:12 ` Arnd Bergmann
2019-07-23 8:28 ` Christian Brauner
2019-07-23 8:45 ` Arnd Bergmann
2019-07-25 0:04 ` Alistair Francis
2019-07-25 4:40 ` Rich Felker [this message]
2019-07-25 13:15 ` Arnd Bergmann
2019-07-25 16:06 ` Christian Brauner
2019-07-25 17:14 ` Eric W. Biederman
2019-07-25 17:30 ` Christian Brauner
2019-08-13 22:22 ` Alistair Francis
2019-08-13 23:11 ` Rich Felker
2019-08-14 5:07 ` Christian Brauner
2019-08-14 11:38 ` [PATCH v1 0/1] waitid: process group enhancement christian.brauner
2019-08-14 11:38 ` [PATCH v1 1/1] waitid: Add support for waiting for the current process group christian.brauner
2019-08-14 12:29 ` Oleg Nesterov
2019-08-14 12:45 ` Christian Brauner
2019-08-14 12:50 ` Oleg Nesterov
2019-08-14 12:53 ` Christian Brauner
2019-08-14 13:07 ` [PATCH v2 0/1] waitid: process group enhancement Christian Brauner
2019-08-14 13:07 ` [PATCH v2 1/1] waitid: Add support for waiting for the current process group Christian Brauner
2019-08-14 14:19 ` Oleg Nesterov
2019-08-14 14:35 ` Christian Brauner
2019-08-14 15:27 ` Oleg Nesterov
2019-08-14 15:30 ` Christian Brauner
2019-08-14 15:43 ` [PATCH v3 0/1] waitid: process group enhancement Christian Brauner
2019-08-14 15:44 ` [PATCH v3 1/1] waitid: Add support for waiting for the current process group Christian Brauner
2019-08-14 16:09 ` Oleg Nesterov
2019-08-14 16:15 ` Christian Brauner
2019-08-14 16:34 ` Christian Brauner
2019-08-14 16:55 ` Rich Felker
2019-08-14 17:02 ` Christian Brauner
2019-08-14 17:06 ` Linus Torvalds
2019-08-14 18:00 ` Rich Felker
2019-08-14 20:50 ` Christian Brauner
2019-08-14 15:58 ` [PATCH v3 0/1] waitid: process group enhancement Rich Felker
2019-08-14 16:13 ` Christian Brauner
2019-07-26 23:35 ` [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable Alistair Francis
2019-07-17 0:08 ` [RFC v3 04/23] sysdeps/clock_gettime: Use clock_gettime64 " Alistair Francis
2019-07-17 5:38 ` Florian Weimer
2019-07-17 8:04 ` Arnd Bergmann
2019-07-17 8:44 ` Florian Weimer
2019-07-17 9:10 ` Arnd Bergmann
2019-07-17 15:16 ` Florian Weimer
2019-07-18 7:38 ` Arnd Bergmann
2019-07-18 8:18 ` Florian Weimer
2019-07-18 9:14 ` Arnd Bergmann
2019-07-18 18:10 ` Adhemerval Zanella
2019-07-19 21:03 ` Alistair Francis
2019-07-17 7:03 ` Andreas Schwab
2019-07-17 12:37 ` Lukasz Majewski
2019-07-17 0:08 ` [RFC v3 05/23] sysdeps/timespec_get: " Alistair Francis
2019-07-17 5:08 ` Florian Weimer
2019-07-17 7:59 ` Arnd Bergmann
2019-07-17 8:11 ` Florian Weimer
2019-07-17 8:23 ` Arnd Bergmann
2019-07-17 8:41 ` Florian Weimer
2019-07-17 8:54 ` Arnd Bergmann
2019-07-25 20:14 ` Joseph Myers
2019-07-17 12:22 ` Lukasz Majewski
2019-07-17 0:08 ` [RFC v3 06/23] Documentation for the RISC-V 32-bit port Alistair Francis
2019-07-17 0:08 ` [RFC v3 07/23] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2019-07-17 8:27 ` Arnd Bergmann
2019-07-17 22:39 ` Alistair Francis
2019-07-18 7:41 ` Arnd Bergmann
2019-07-18 17:36 ` Alistair Francis
2019-07-19 6:44 ` Arnd Bergmann
2019-07-19 17:02 ` Alistair Francis
2019-07-17 0:09 ` [RFC v3 08/23] RISC-V: define __NR_futex as __NR_futex_time64 for 32-bit Alistair Francis
2019-07-17 0:09 ` [RFC v3 09/23] RISC-V: define __NR_* as __NR_*_time64/64 " Alistair Francis
2019-07-17 0:09 ` [RFC v3 10/23] RISC-V: define __NR_clock_getres as __NR_*_time64 " Alistair Francis
2019-07-17 0:09 ` [RFC v3 11/23] RISC-V: define __vdso_clock_getres as __vdso_clock_getres_time64 " Alistair Francis
2019-07-17 0:09 ` [RFC v3 12/23] RISC-V: define __vdso_clock_gettime as __vdso_clock_gettime64 " Alistair Francis
2019-07-17 8:16 ` Arnd Bergmann
2019-07-19 17:15 ` Alistair Francis
2019-07-17 0:09 ` [RFC v3 13/23] RISC-V: Use 64-bit timespec in clock_gettime vdso calls Alistair Francis
2019-07-17 8:13 ` Arnd Bergmann
2019-07-17 0:09 ` [RFC v3 14/23] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
2019-07-17 0:09 ` [RFC v3 15/23] RISC-V: Add path of library directories " Alistair Francis
2019-07-17 12:20 ` Florian Weimer
2019-07-17 0:09 ` [RFC v3 16/23] RISC-V: The ABI implementation " Alistair Francis
2019-07-17 0:09 ` [RFC v3 17/23] RISC-V: Hard float support for the 32 bit Alistair Francis
2019-07-17 0:09 ` [RFC v3 18/23] RISC-V: Regenerate ULPs of RISC-V Alistair Francis
2019-07-17 0:09 ` [RFC v3 19/23] RISC-V: Add ABI lists Alistair Francis
2019-07-17 0:09 ` [RFC v3 20/23] RISC-V: Build Infastructure for the 32-bit Alistair Francis
2019-07-17 0:09 ` [RFC v3 21/23] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
2019-07-17 12:22 ` Florian Weimer
2019-07-17 22:32 ` Alistair Francis
2019-07-17 0:09 ` [RFC v3 22/23] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
2019-07-17 0:09 ` [RFC v3 23/23] RISC-V: Use 64-bit vdso syscalls Alistair Francis
2019-07-17 5:33 ` Florian Weimer
2019-07-17 8:02 ` Arnd Bergmann
2019-07-17 22:23 ` Alistair Francis
2019-07-17 23:42 ` Alistair Francis
2019-07-18 0:01 ` Alistair Francis
2019-07-19 17:14 ` [RFC v3 00/23] RISC-V glibc port for the 32-bit Alistair Francis
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190725044009.GJ1506@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=adhemerval.zanella@linaro.org \
--cc=akpm@linux-foundation.org \
--cc=alistair.francis@wdc.com \
--cc=alistair23@gmail.com \
--cc=arnd@arndb.de \
--cc=christian@brauner.io \
--cc=ebiederm@xmission.com \
--cc=fweimer@redhat.com \
--cc=hpa@zytor.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@wdc.com \
--cc=palmer@sifive.com \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=zongbox@gmail.com \
/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).