On Mon, Aug 30, 2021 at 11:11:55AM +0200, Martin Pieuchot wrote:
> On 13/07/21(Tue) 00:55, Anindya Mukherjee wrote:
> > On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson wrote:
> > > On 2021/07/03 01:09, Anindya Mukherjee wrote:
> > > > Thanks for the discussion. This has been very
On 13/07/21(Tue) 00:55, Anindya Mukherjee wrote:
> On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson wrote:
> > On 2021/07/03 01:09, Anindya Mukherjee wrote:
> > > Thanks for the discussion. This has been very illuminating. I have been
> > > digging
> > > around in /usr/src/ and ignoring
Hi, just a quick update. After about two weeks, various counters have exceeded
the 32 bit int limit, and haven't wrapped. There might eventually be some issues
with the field width but that will take a long time to reach.
Regards,
Anindya
On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart
On Sat, Jul 03, 2021 at 11:20:42AM +0100, Stuart Henderson wrote:
> On 2021/07/03 01:09, Anindya Mukherjee wrote:
> > Thanks for the discussion. This has been very illuminating. I have been
> > digging
> > around in /usr/src/ and ignoring the atomic architectures (where I got
> > stuck) it
> >
One issue I have on amd64 while trying to build the kernel with all uvmexp
members promoted to uint64_t is the use of atomic operations. For example,
swpgonly is modified atomically in several places and those expect an int. I
think only a few members are accessed in this way.
On Sat, Jul 03,
On 2021/07/03 01:09, Anindya Mukherjee wrote:
> Thanks for the discussion. This has been very illuminating. I have been
> digging
> around in /usr/src/ and ignoring the atomic architectures (where I got stuck)
> it
> looks like it should be possible to use uint64_t everywhere. I'm playing with
>
Thanks for the discussion. This has been very illuminating. I have been digging
around in /usr/src/ and ignoring the atomic architectures (where I got stuck) it
looks like it should be possible to use uint64_t everywhere. I'm playing with
some changes on my machine to see if I can get at least
Claudio Jeker wrote:
> I know that golang has its definition of uvmexp and so if you change the
> ABI then you would break at least that. struct uvmexp is used more often
> than we would like.
It is a huge ABI change. If we are going to change the size of the subunits,
we have to get it right
On 2021/07/02 13:43, Stuart Henderson wrote:
> Go has its own translated copy of structs from system headers (e.g.
> in golang.org/x/sys/unix/zsysctl_openbsd_*) and these are bundled in
> many ports that use go (even core system libraries are not exempt from
> "vendoring" or having old versions
On 2021/07/02 13:09, Martin Pieuchot wrote:
> On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote:
> > Hi,
> >
> > I noticed that if I leave the system running for more than about a month,
> > some
> > of the counters in the uvm view of systat(1) overflow and become negative.
> > This
> > is
On Fri, Jul 02, 2021 at 01:09:05PM +0200, Martin Pieuchot wrote:
> On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote:
> > Hi,
> >
> > I noticed that if I leave the system running for more than about a month,
> > some
> > of the counters in the uvm view of systat(1) overflow and become negative.
>
On 01/07/21(Thu) 13:53, Anindya Mukherjee wrote:
> Hi,
>
> I noticed that if I leave the system running for more than about a month, some
> of the counters in the uvm view of systat(1) overflow and become negative.
> This
> is because the members of struct uvmexp in sys/uvm/uvmexp.h are ints.
Hi,
I noticed that if I leave the system running for more than about a month, some
of the counters in the uvm view of systat(1) overflow and become negative. This
is because the members of struct uvmexp in sys/uvm/uvmexp.h are ints. The
kernel's internal counters are of course uint64_t so they
13 matches
Mail list logo
