NetBSD-10.0 virtual memory improvements
Hello, I was interested to read the following release notes: Various optimizations for the machine-independent virtual memory system: - Switched to a faster radix tree algorithm for memory page lookups. - Improved tracking of clean/dirty pages, speeding up fsync(2) on large files by orders of magnitude. - Improved parallelization: rewritten page allocator with awareness of CPU topology, replaced global counters with per-CPU counters, and reduced lock contention. I ran a quick performance test on the scalability of NetBSD-10.0 with regard to handling page faults on x86-64 for up to 8 concurrent threads. To be honest, I'm not noticing any improvements compared to NetBSD-9.3. Compared to Linux, FreeBSD and Solaris, NetBSD is way at the bottom in terms of paging performance. Is there a specific sysctl that needs to be enabled or the "improved parallelization" above is referring to some other aspect of page handling? I'm not subscribed to this list, please CC me in your replies. Thanks.
Re: tickless kernel - high level roadmap ideas
> On Wed, 10 Apr 2024 12:37:31 +, Ice Cream > said: >> I've been working a little bit on how to tackle tickless in the >> kernel. I'll be hoping to send some preliminary patches later this month >> or so - so this is mostly an email to co-ordinate with anyone else >> working or aiming to work on similar things. > Hi, I'm aiming to work on this project as well. >> One of the first things needed will be to discover and manage underlying >> hardware timers which can interrupt at arbitrary (and/or repetitive) >> timeouts. Therefore, one of the first things I'll be working on is how >> to abstract this management. Since we need to support a variety of >> platform/CPU/CPU-package configurations, this will be the part with a >> large number of cross platform dependencies. > Since you'll be working on this, I'll start with researching about the next > step, > that is, the callout variants using bintime and the usage of the new timer > API. Brilliant! Let's take the details offline, so that we don't spam the list. I'll email you separately. -- Math/(~cherry)
Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplayttydevices
uwe@ wrote: > > On the other hand, news68k (and sun) machines have putchar() > > that also handles virtual terminal ops like backspace, CR/LF, > > and even scrolling at the bottom of screen. In this case > > no VT emulation layer is necessary in the kernel side, > > so kernel's putc(9) just calls firmware's putchar(), > > and for userland processes we can simply pass translated > > wskbd inputs to line discipline of the tty device. > > > > That's the reason why I proposed to add register/deregister > > APIs to pass wskbd data to romcons tty device. > > > > What do you think about this case? > > Add trivial wsemul_none (or wsemul_delegate, or whatever a suitable > name might be) that does even less than wsemul_dumb and only ever uses > putchar to pass chars to the firmware emulator? I considered about it when I tried to implement news68k ROM console driver, but I gave it up because: - wscons(9) was the most complicated driver with undocumented APIs (struct wsemul_ops etc.) - wsdisplay(9) would pull a lot of unnecessary sources like wsdisplay.c etc. (for screen ops) while TERM=wsvt25 could not be used - there was no sample implementation using "putchar() with VT emulation" - on the other hand there were simple implementation for PROM console functions (sys/arch/sun3/dev/kd.c and sys/dev/ofw/ofcons.c etc.) and actually it was quite simple to connect wskbd(4) to "romcons" driver Thanks, --- Izumi Tsutsui
Re: tickless kernel - high level roadmap ideas
> I've been working a little bit on how to tackle tickless in the > kernel. I'll be hoping to send some preliminary patches later this month > or so - so this is mostly an email to co-ordinate with anyone else > working or aiming to work on similar things. Hi, I'm aiming to work on this project as well. > One of the first things needed will be to discover and manage underlying > hardware timers which can interrupt at arbitrary (and/or repetitive) > timeouts. Therefore, one of the first things I'll be working on is how > to abstract this management. Since we need to support a variety of > platform/CPU/CPU-package configurations, this will be the part with a > large number of cross platform dependencies. Since you'll be working on this, I'll start with researching about the next step, that is, the callout variants using bintime and the usage of the new timer API. -- IC
