Re: [uvm_hotplug] Fixing the build of tests
Le sam. 15 déc. 2018 à 15:27, Jason Thorpe a écrit : > We can buy ourselves some time on aarch64 by using a different page size, > yes? iOS, for example, uses 16KiB VM pages (backed by 4KiB or 16KiB physical > pages, depending on the specific CPU type). I don't think the ARM eabi has > the same section alignment issue that made the 4K/8K page size thing on m68k > such a pain. > Bigger physical pages also reduce size of page tables (big deal if it e.g. allows to reduce e.g. 4-level to 3-level mapping, but even "just" factor or two or four is very good) and hence speed up page faults, and improve TLB utilization. It's really good thing overall and something which is very desirable on monster memory machines. Jaromir
Re: Support for tv_sec=-1 (one second before the epoch) timestamps?
On Sat, Dec 15, 2018, 1:17 PM Mouse > Might I suggest that the obvious solution to this, and probably a > > host of other issues, is to make time_t an always negative number > > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, > > 19 January 2038, > > While it's academic as far as this thread is concerned, you can get > much the same effect by making time_t a (positive) unsigned value and > redefining the epoch to be 1901-12-13 20:45:54 UTC. > No, it is not. That breaks the naive seconds since 1970 to/from broken down time that is specified in the standard (which is a fatal flaw since it assigns no unique value to leap seconds, pretending that they don't exist). Warner > But, if you're going to redefine the epoch, there are a whole lot of > options available. > > /~\ The ASCII Mouse > \ / Ribbon Campaign > X Against HTMLmo...@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B >
Re: Support for tv_sec=-1 (one second before the epoch) timestamps?
> Might I suggest that the obvious solution to this, and probably a > host of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, > 19 January 2038, While it's academic as far as this thread is concerned, you can get much the same effect by making time_t a (positive) unsigned value and redefining the epoch to be 1901-12-13 20:45:54 UTC. But, if you're going to redefine the epoch, there are a whole lot of options available. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Support for tv_sec=-1 (one second before the epoch) timestamps?
> Date: Sat, 15 Dec 2018 10:30:13 +0100 > From: theo4...@borm.org > > Might I suggest that the obvious solution to this, and probably a host > of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, 19 > January 2038, leaving (time-t) -1 as a special value for errors and > halting the system when the clock would overflow to (time-t) 0 > (ENOMORETIME). A cute idea, but we already dealt with this problem a decade ago by making time_t 64-bit on every platform.
Re: [uvm_hotplug] Fixing the build of tests
> On Dec 15, 2018, at 12:51 AM, matthew green wrote: > > we have a general problem in UVM we need to confront some time > fairly soon. it won't be easy to find all the places, and it > won't be easy to test we have found them. > > almost all the page counts in UVM are "int". that overflows > at 8TiB for 4KiB pages. > > i see that HP have a machine with 48 TiB ram available today. We can buy ourselves some time on aarch64 by using a different page size, yes? iOS, for example, uses 16KiB VM pages (backed by 4KiB or 16KiB physical pages, depending on the specific CPU type). I don't think the ARM eabi has the same section alignment issue that made the 4K/8K page size thing on m68k such a pain. When you start talking about such large memory configurations, it's not just the size of your pgcnt_t that's an issue, but how well some of your other data structures scale, too. Simply managing fewer vm_page_t's can help. > we really need to introduce an MD "page count" type, that we > can leave as int (or even unsigned -- most uses do not want > negative values) on most platform, but increase on those with > massive ram capability (arm64, amd64, ...?). Yah, I agree that would be a good idea. I propose "pgcnt_t" as the name. > (one method to help find violations between old 32 bit values > and new 64 bit values is to make the 64 bit value a pointer, > which triggers conversion to different size warnings, and eg, > display needs a PRIx, etc., set, as well as > other things likely to come up. it seems worth paying the > price given the almost impossible task of finding all the > conversions by hand.) Yah, I think that's a clever trick to use, but I'm not sure it should be kept once the audit / fix-up is complete (unless a really good explanatory comment is included along with it). -- thorpej
Re: [uvm_hotplug] Fixing the build of tests
> (one method to help find violations between old 32 bit values and new > 64 bit values is to make the 64 bit value a pointer, which triggers > conversion to different size warnings, and eg, display needs a > PRIx, etc., set, as well as other things likely to > come up. it seems worth paying the price given the almost impossible > task of finding all the conversions by hand.) Or make the new value a struct containing the actual value - you don't need casts, you aren't using a conceptually wrong type, and the resulting code is in most cases just as small and fast as using the undecorated 64-bit type. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Support for tv_sec=-1 (one second before the epoch) timestamps?
On 12/12/18 8:46 PM, Michał Górny wrote: Hi, While researching libc++ test failures, I've discovered that NetBSD suffers from the same issue as FreeBSD -- that is, both the userspace tooling and the kernel have problems with (time_t)-1 timestamp, i.e. one second before the epoch. For example: Might I suggest that the obvious solution to this, and probably a host of other issues, is to make time_t an always negative number (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, 19 January 2038, leaving (time-t) -1 as a special value for errors and halting the system when the clock would overflow to (time-t) 0 (ENOMORETIME). regards, theo
Re: [uvm_hotplug] Fixing the build of tests
On Sat, Dec 15, 2018 at 2:26 PM matthew green wrote: > > > I believe the right thing to do would be to just fix the type in > > uvmexp.npages to the correct type instead of adjusting the test > > to accommodate it. What would be the consequences of this? > > > > Also, I hadn't realised that the tests aren't wired into the > > build. They really should be. > > please don't change any of the structures randomly -- see my > previous email for the major issue needing to be resolved, > which will end up making this better. (if you look closely, > you'll see that the external interface is already 64 bit, > it's only the internal code that is problematic. oh well, > it would be the much less hard to fix part ... :-) > This is good insight, thank you mrg for that. And I agree with the not changing structures randomly. (Especially by someone like me who is just getting to see how things work.) > ie, i support the change as proposed, ugly as it may be. > Yes the fix is a bit ugly. But the tests can be adapted as the interface evolves. I do not mind holding the responsibility of keeping the tests updated as the interface evolves. > > .mrg. -- Santhosh
re: [uvm_hotplug] Fixing the build of tests
> I believe the right thing to do would be to just fix the type in > uvmexp.npages to the correct type instead of adjusting the test > to accommodate it. What would be the consequences of this? > > Also, I hadn't realised that the tests aren't wired into the > build. They really should be. please don't change any of the structures randomly -- see my previous email for the major issue needing to be resolved, which will end up making this better. (if you look closely, you'll see that the external interface is already 64 bit, it's only the internal code that is problematic. oh well, it would be the much less hard to fix part ... :-) ie, i support the change as proposed, ugly as it may be. .mrg.
re: [uvm_hotplug] Fixing the build of tests
semi-related, but perhaps a change to begin marking places we need to fix... > The reason for failure was the comparison between psize_t (which is > defined as unsigned log inside t_uvm_hotplug.c) and int resulting in a > sign compare error (-Werror=sign-compare). This was used to compare > the "npages" variable inside uvmexp struct. > > I have fixed the build by doing a type cast of uvmexp.npages to > psize_t and the changes have been attached as diff along with this > mail. The rationale for this is that uvmexp.npages is not expected to > go below zero and hence the type cast does not result in negative > values being converted to unsigned long. we have a general problem in UVM we need to confront some time fairly soon. it won't be easy to find all the places, and it won't be easy to test we have found them. almost all the page counts in UVM are "int". that overflows at 8TiB for 4KiB pages. i see that HP have a machine with 48 TiB ram available today. we really need to introduce an MD "page count" type, that we can leave as int (or even unsigned -- most uses do not want negative values) on most platform, but increase on those with massive ram capability (arm64, amd64, ...?). (one method to help find violations between old 32 bit values and new 64 bit values is to make the 64 bit value a pointer, which triggers conversion to different size warnings, and eg, display needs a PRIx, etc., set, as well as other things likely to come up. it seems worth paying the price given the almost impossible task of finding all the conversions by hand.) .mrg.
