Re: veriexec(4) maintenance
On Thu, Aug 03, 2023 at 03:03:06PM +0930, Brett Lymn wrote: > > If anyone cares about veriexec(4) and would like to volunteer to take > > this on, we can discuss what needs to be done and how to proceed. > > I will take this on since I was originally responsible for the mess. It > does play fast and loose with synchronisation and should be fixed. > > I have some fixes in my private tree that went some way to addressing > the issues but they have been languishing for many many years because I > had an issue of a deadlock that would occaisionally occur. At the time > I couldn't work out where the deadlock was coming from but maybe with > some expert help and the improved tools I can nut it out. I was looking at this last weekend and for veriexec I have one fix and some comments/notes, which I should probably commit. fileassoc I would recommend flushing and replacing with a proper specificdata implementation for vnodes, which there should be no particular barrier to. fileassoc is trying to be that but it's both bust and doing it wrong. :-| -- David A. Holland dholl...@netbsd.org
Re: Maxphys on -current?
> On 4. Aug 2023, at 21:48, Jaromír Doleček wrote: > In a broader view, I have doubts if there is any practical reason to > even have support for bigger than 64kb block size support at all. Having tapes with record size > 64k would be a real benefit though. -- J. Hannken-Illjes - hann...@mailbox.org signature.asc Description: Message signed with OpenPGP
Re: Maxphys on -current?
Le ven. 4 août 2023 à 17:27, Jason Thorpe a écrit : > If someone does pick this up, I think it would be a good idea to start from > scratch, because MAXPHYS, as it stands, is used for multiple things. > Thankfully, I think it would be relatively straightforward to do the work > that I am suggesting incrementally. > I believe I've been the last one to look at the tls maxphys branch and at least update it. I agree that it's likely more useful to start it from scratch and do incremental updates. Certainly physio before block interface, and also by controller type, e.g. ATA first and then SCSI or USB. For the branch, I particularly disliked that there were quite a few changes which looked either unrelated, or avoidable. As one of the first steps I've planned to reduce diffs against HEAD. I've not gotten to it yet however. Le ven. 4 août 2023 à 08:04, Brian Buhrow a écrit : > speed of the transfers on either system. Interestingly enough, however, the > FreeBSD > performance is markedly worse on this test. > ... > NetBSD-99.77/amd64 with SATA3 disk > # dd if=/dev/rwd0a of=/dev/null bs=1m count=5 > 5242880 bytes transferred in 292.067 secs (179509496 bytes/sec) > > FreeBSD-13.1/AMD64 with SATA3 disk > # dd if=/dev/da4 of=/dev/null bs=1m count=5 > 5242880 bytes transferred in 322.433936 secs (162603232 bytes/sec) Interesting. FreeBSD da(4) is a character device since FreeBSD has no block devices anymore, so it's not a raw-vs-block device difference. Is the hardware really similar enough to be a fair comparison? In a broader view, I have doubts if there is any practical reason to even have support for bigger than 64kb block size support at all. For HDDs over SATA maybe - the bigger blocks mean potentially more sequential I/O and hence higher total throughput. Also you can queue more I/O and hence avoid the seeks - current NetBSD maximum on SATA is 32 x 64KiB = 2048KiB of queued I/O. For SCSI, you can queue way more I/O than the usual disk cache can hold even with 64KiB blocks, so bigger block size is not very important. Still, I doubt >64KiB blocks on HDD would achieve more than a couple of percent increase over 64KiB ones. For SSDs over SATA, there is no seek to worry about, but the command latency is a concern. But even there, according to Linux benchmarks, the total transfer rate tops out with 64KiB blocks already. For NVMe, the command latency is close to irrelevant - it has a very low latency command interface and very deep command queues. I don't see bigger blocks helping much, if at all. Jaromir
Patch for kern/57561: iwm device timeouts
Hi, iwm driver has one watchdog timer for the aggregate Tx queue. And it resets the interface when the watchdog fires resulting in loss of connectivity. The workaround for this issue is executing ifconfig iwm0 down ifconfig iwm0 up Here is the dump of logs when this reset happens: [ 185.741855] iwm0: autoconfiguration error: device timeout [ 185.741855] iwm0: autoconfiguration error: dumping device error log [ 185.741855] iwm0: autoconfiguration error: Start Error Log Dump: [ 185.741855] iwm0: autoconfiguration error: Status: 0x63, count: 6 [ 185.741855] iwm0: autoconfiguration error: 22CE | ADVANCED_SYSASSERT [ 185.741855] iwm0: autoconfiguration error: 02B3 | trm_hw_status0 [ 185.741855] iwm0: autoconfiguration error: | trm_hw_status1 [ 185.741855] iwm0: autoconfiguration error: E258 | branchlink2 [ 185.741855] iwm0: autoconfiguration error: 0002730C | interruptlink1 [ 185.741855] iwm0: autoconfiguration error: | interruptlink2 [ 185.741855] iwm0: autoconfiguration error: 001C | data1 [ 185.741855] iwm0: autoconfiguration error: 0323 | data2 [ 185.741855] iwm0: autoconfiguration error: DEADBEEF | data3 [ 185.741855] iwm0: autoconfiguration error: 9D401E06 | beacon time [ 185.741855] iwm0: autoconfiguration error: 272AA1FD | tsf low [ 185.741855] iwm0: autoconfiguration error: 002F | tsf hi [ 185.741855] iwm0: autoconfiguration error: | time gp1 [ 185.741855] iwm0: autoconfiguration error: 041C1813 | time gp2 [ 185.741855] iwm0: autoconfiguration error: | uCode revision type [ 185.741855] iwm0: autoconfiguration error: 0016 | uCode version major [ 185.741855] iwm0: autoconfiguration error: 00058404 | uCode version minor [ 185.741855] iwm0: autoconfiguration error: 0230 | hw version [ 185.741855] iwm0: autoconfiguration error: 9000 | board version [ 185.741855] iwm0: autoconfiguration error: 001C | hcmd [ 185.741855] iwm0: autoconfiguration error: 22F12000 | isr0 [ 185.741855] iwm0: autoconfiguration error: 4000 | isr1 [ 185.741855] iwm0: autoconfiguration error: 1802 | isr2 [ 185.741855] iwm0: autoconfiguration error: 40417DC1 | isr3 [ 185.741855] iwm0: autoconfiguration error: | isr4 [ 185.741855] iwm0: autoconfiguration error: 10900112 | last cmd Id [ 185.741855] iwm0: autoconfiguration error: | wait_event [ 185.741855] iwm0: autoconfiguration error: 0080 | l2p_control [ 185.741855] iwm0: autoconfiguration error: 00011C22 | l2p_duration [ 185.741855] iwm0: autoconfiguration error: 003F | l2p_mhvalid [ 185.741855] iwm0: autoconfiguration error: 00CE | l2p_addr_match [ 185.741855] iwm0: autoconfiguration error: 000D | lmpm_pmg_sel [ 185.741855] iwm0: autoconfiguration error: 03071928 | timestamp [ 185.741855] iwm0: autoconfiguration error: 15E4A0A0 | flow_handler [ 185.741855] iwm0: autoconfiguration error: Start UMAC Error Log Dump: [ 185.741855] iwm0: autoconfiguration error: Status: 0x63, count: 7 [ 185.741855] iwm0: autoconfiguration error: 0x0070 | ADVANCED_SYSASSERT [ 185.741855] iwm0: autoconfiguration error: 0x | umac branchlink1 [ 185.741855] iwm0: autoconfiguration error: 0xC0082F64 | umac branchlink2 [ 185.741855] iwm0: autoconfiguration error: 0xC0081000 | umac interruptlink1 [ 185.741855] iwm0: autoconfiguration error: 0xC0081000 | umac interruptlink2 [ 185.741855] iwm0: autoconfiguration error: 0x0800 | umac data1 [ 185.741855] iwm0: autoconfiguration error: 0xC0081000 | umac data2 [ 185.741855] iwm0: autoconfiguration error: 0xDEADBEEF | umac data3 [ 185.741855] iwm0: autoconfiguration error: 0x0016 | umac major [ 185.741855] iwm0: autoconfiguration error: 0x00058404 | umac minor [ 185.741855] iwm0: autoconfiguration error: 0xC0886280 | frame pointer [ 185.741855] iwm0: autoconfiguration error: 0xC0886280 | stack pointer [ 185.741855] iwm0: autoconfiguration error: 0x092B002C | last host cmd [ 185.741855] iwm0: autoconfiguration error: 0x | isr status reg The status register value 0x63 does not seem to indicate anything is wrong with the device. Linux and OpenBSD handle this issue by creating a timer per Tx queue, and the reasoning is just because some Tx queues get stuck sometimes does not mean we should reset the interface. I don't know whether those stuck queues ever get unblocked. But, with this patch, I am not experiencing any loss of WiFi. I modeled this patch on Stefan Sperling's patch in OpenBSD for the same issue: https://www.mail-archive.com/tech@openbsd.org/msg66949.html Please review. Best, Salil iwm-patch.diff Description: Binary data
Re: Maxphys on -current?
> On Aug 3, 2023, at 2:19 PM, Brian Buhrow wrote: > > hello. I know that this has ben a very long term project, but I'm wondering > about the > status of this effort? I note that FreeBSD-13 has a Maxphys value of 1048576 > bytes. > Have we found other ways to get more throughput from ATA disks that obviate > the need for this > setting which I'm not aware of? > If not, is anyone working on this project? The wiki page says the project is > stalled. If someone does pick this up, I think it would be a good idea to start from scratch, because MAXPHYS, as it stands, is used for multiple things. Thankfully, I think it would be relatively straightforward to do the work that I am suggesting incrementally. Here goes... MAXPHYS is really supposed to be “maximum transfer via physio”, which is the code path you use when you open /dev/rsd0e and read/write to it. The user-space pages are wired and mapped into the kernel for the purpose of doing I/O. MAXPHYS is a per-architecture constant because some systems have different constraints as to how much KVA space can be used for that at any given time. Unfortunately, some of the adjacent physio machinery (e.g. minphys()) is also used for other purposes, specifically to clamp I/O sizes to constraints defined by the physical device and/or the controllers / busses they’re connected to. Logically, these are two totally separate things, and IMO they should be cleanly separated. What we *should* have is the notion of “I/O parameters” that are defined by the device… max I/O size, max queue depth, preferred I/O size, preferred I/O alignment, physical block size, logical block size, etc. The base values for these parameters should come from the leaf device (e.g.. the disk), and then be clamped as needed by it’s connective tissue (the controller, the system bus the controller is connected to, and ultimately the platform-specific e.g. DMA constraints). The the interface layers (the page cache / UBC, the traditional block I/O buffer cache, and the physio interface for user-space) can further impose their own constraints, as necessary per their API contract. There is zero reason that MAXPHYS should impact the maximum I/O that a file system can do via the UBC, for example. (In a perfect world, we wouldn’t even have to consume virtual address space to bring data and and out of the page cache / UBC, because we already know the physical addresses of the pages that are being pulled in / cleaned.) > Any thoughts or news would be greatly appreciated. Anyway, there are mine :-) -- thorpej
Re: Maxphys on -current?
On Thu, Aug 03, 2023 at 11:04:18PM -0700, Brian Buhrow wrote: > speed of the transfers on either system. Interestingly enough, however, the > FreeBSD > performance is markedly worse on this test. 162MB/s or 179MB/s is just the speed of the disk, so I would guess the disks are different. There might also be some difference in command queuing parameters, some disks get slower for this kind of test. -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Maxphys on -current?
Hasn't there been a tls-maxphys branch?
