Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 24 Nov 2017 15:24:53 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Bruce Evans <brde@optusnet.com.au>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r326073 - head/usr.bin/systat
Message-ID:  <20171124132453.GY2272@kib.kiev.ua>
In-Reply-To: <20171124225011.V1289@besplex.bde.org>
References:  <201711211955.vALJtWhg047906@repo.freebsd.org> <20171122071838.R1172@besplex.bde.org> <20171122103917.GS2272@kib.kiev.ua> <20171123021646.M1933@besplex.bde.org> <20171122220538.GT2272@kib.kiev.ua> <20171123224032.A992@besplex.bde.org> <20171123151849.GU2272@kib.kiev.ua> <20171124184535.E980@besplex.bde.org> <20171124105720.GW2272@kib.kiev.ua> <20171124225011.V1289@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 25, 2017 at 12:14:10AM +1100, Bruce Evans wrote:
> On Fri, 24 Nov 2017, Konstantin Belousov wrote:
> 
> > On Fri, Nov 24, 2017 at 08:15:06PM +1100, Bruce Evans wrote:
> >> On Thu, 23 Nov 2017, Konstantin Belousov wrote:
> >* ...
> >>>> #define	pgtok(p)	((uintmax_t)(p) * pageKilo)
> >>> Amusingly there is already MD macro in machine/param.h with the same name
> >>> and same intent, but as you formulate it, sloppy implementation.  It uses
> >>> unsigned long cast on almost all 64bit arches, except powerpc.  For 32bit
> >>> arches, the cast is not done, unfortunately.
> >>
> >> I already pointed out the system pgtok().
> >>
> >> It was almost correct to cast to u_int on all arches because the
> >> implementation can know the size of all its page counters.  That was int
> >> or u_int, and the expansion factor is small.  In practice, 32-bit systems
> >> never have enough memory to overflow in K (that happens at 4TB), and
> >> 64-bit systems that overflow in K are close to overflowing the page
> >> counters (that happens at 16TB with 4K-pages).
> >>
> >> The pgtok() is just unusable because the page size can vary.
> > No, it is unusable only due to the implementation not ensuring the consistent
> > output type.
> 
> Hmm, I couldn't find any arch with even a compile-time variable PAGE_SIZE.
> It is currently just unportable in theory to use hard-coded PAGE_SIZE or
> macros that use it.
sparc64 uses 8K, Itanium had compile-time variable page size supported by
hardware.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171124132453.GY2272>