Re: [HACKERS] memory fields from getrusage() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] memory fields from getrusage()
Date
Msg-id CA+TgmobD65pYq0mAt+kpqTzvnkuLV88G6Ae3pM_MJfd8PCa5Kg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] memory fields from getrusage()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] memory fields from getrusage()
List pgsql-hackers
On Sat, Jun 10, 2017 at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We already do call getrusage().  The point of that comment is that the
> contents of the resulting struct rusage are not very well standardized.
> POSIX says only
>
>     The <sys/resource.h> header defines the rusage structure that includes
>     at least the following members:
>
>         struct timeval ru_utime   user time used
>         struct timeval ru_stime   system time used
>
> (seems the same in 1997 and 2008 text).  So the existing code has already
> got its neck stuck way out in terms of portability.  Maybe you could push
> it further, but I bet you'll find that the situation isn't any better than
> it was at the time that comment was written.
>
> It's entirely possible that we could simplify the code some, because
> I suspect that Windows is the only remaining platform that doesn't
> HAVE_GETRUSAGE.  But that in itself doesn't mean we can use any more
> fields than we do now.

It might be worth adding platform-specific code for common platforms.

I checked macOS X 10.10.5 (Yosemite) and a Linux system (hydra, old
Fedora release) and they seem to list identical fields for struct
rusage, which is good as far as it goes, but Linux documents a bunch
of the interesting fields (ru_ixrss, ru_idrss, ru_isrss, ru_nswap,
ru_msgsnd, ru_msgrcv, ru_nsignals) as unused, and apparently returns
ru_maxrss in kilobytes where macOS reports it in bytes.  It seems like
it would be a good idea to install code specific to Linux that
displays all and only those values that are meaningful on Linux, and
(less importantly) similarly for macOS.  Linux is such a common
platform that reporting bogus zero values and omitting other fields
that are actually meaningful does not seem like a very good plan.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: [HACKERS] Typo in BRIN documentation
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] RTE_NAMEDTUPLESTORE, enrtuples and comments