• Change man page wording.
• Call the flag KVME_FLAG_USER_WIRED; we do not set it if the mapping is wired by vslock().

In D19390#416570, @markj wrote:

IMO the concept should be defined at the mapping level, not at the level of the physical page; to effect wiring, the VM can use the reference counter to ensure that the page is not reclaimable, and the PG_USER_WIRED flag caches the information that at least one non-kernel mapping of the page is wired. This is similar in principle to, e.g., PGA_WRITEABLE.

In D19390#416489, @kib wrote:

[I am not suggesting to redo the patch, only discussing the possible approaches].

In D19227#415998, @noah.bergbauer_tum.de wrote:

Feel free to break the change into multiple patches. The change to use a TAILQ could certainly be committed on its own as a "no functional change" diff.

Not sure how to do this? My current workflow is copy-pasting the output of svnlite diff into phabricator. I'm not aware of a convenient way to split up diffs like this.

In D19265#415876, @cem wrote:

In D19265#415826, @markj wrote:

Ah, I assumed this was a port from OneFS. I'll try running the suite this afternoon.

Thanks!

In D19265#415623, @cem wrote:

In D19265#415545, @markj wrote:

In D19265#414685, @cem wrote:

In D19265#413741, @markj wrote:

My notion is that any time a script refers to a constval args[n], libdtrace would emit the "load immediate" DIF instruction which loads the constant value into a register, and any time it refers to a non-constval args[n+1], libdtrace knows to emit DIF with the ABI argument index shifted to take into account the fact that args[n] isn't represented in the ABI.

That sounds pretty reasonable. Any idea how difficult it would be to implement?

In D18320#415796, @mhorne063_gmail.com wrote:

In D18320#415484, @markj wrote:

Am I right that we only write 4KB at a time?

Yes. I tried writing out more than one page at a time and it failed quite spectacularly, so this could be a good spot to revisit and introduce pmap_kenter_temporary() as we discussed on IRC.

In D19265#414685, @cem wrote:

In D19265#413741, @markj wrote:

Consider that the pid provider (fbt for userspace) has exactly this same problem, and this fix does not address that.

Right; that is a shortcoming of this patch. We could probably fix pid::: in a similar, straightforward (but ugly) fashion. Are there any other Providers that rely on CTF function types?

Looks ok, just a couple of nits.

PS. Due to a note in 4.9.2 I was tempted to always flush pdir, but then backed it off.

In D19315#413467, @kib wrote:

Can you re-upload the diff with the full context added, please ?

• Rebase after removal of sys/dev/drm
• Remove vm_page_(un)hold() prototypes for now

In D18569#414665, @emaste wrote:

Using $( ) instead of ` is an improvement IMO, I'm a little less convinced by some of the new quote use.

This file is pretty inconsistent about the use of braces around variable names; I prefer not to use them unless they're needed, like on line 299 in the new version.

In D19227#412871, @noah.bergbauer_tum.de wrote:

You're right, this should be a linked list. The only reason I went with the reallocation approach is that I wanted to touch as little code as possible to avoid new bugs.

In D19330#414142, @greg_unrelenting.technology wrote:

In D19330#414136, @markj wrote:

I don't really follow. For regular files, O_NONBLOCK means "don't block on open." vn_read() will translate O_NONBLOCK to IO_NDELAY, but most filesystems don't do anything with that. In the snippet you referenced, the code has a comment, "refuse to block when reading," but with this patch shm_read() will block anyway because uiomove_object_page() provides no mechanism for the caller to ask for non-blocking semantics. So either Linux ignores the O_NONBLOCK flag when reading from a shm object and the referenced comment is bogus, or Linux actually honours the flag, in which case this patch isn't sufficient. In the former case, the code should simply be eliminated rather than changing the kernel.

Yes, for regular files, O_NONBLOCK means "don't block on open" — therefore, it doesn't mean anything when the file has already been opened — so it is silently ignored in ioctl/fcntl in vn_ioctl. I'm *only* talking about fcntl, not opening.

As I understand it, the referenced comment isn't bogus, it's defensive code: imagine if a client application passes a pipe or socket instead of the expected file/shm. It would have the ability to make the display server hang forever. The server sets nonblock to prevent that from happening. It's not supposed to do anything in the good case (file/shm was actually sent).

In D19330#414129, @greg_unrelenting.technology wrote:

In D19330#414021, @markj wrote:

What are the semantics on Linux? I can imagine O_NONBLOCK meaning "return EAGAIN if the page is swapped out," in which case this patch is not sufficient.

I haven't looked at Linux, but [[ https://github.com/freebsd/freebsd/blob/724199fd4be1d5274c9fabdfb9bb84778cf8de41/sys/kern/vfs_vnops.c#L1485-L1487 | our semantics for regular files is return (0) ]], so it would make sense to do the same thing between shm and an unlinked file, right?

In D19247#414032, @kib wrote:

In D19247#414025, @markj wrote:

In D19247#413465, @kib wrote:

Don't we need to split the kernel wire/user wire limits for this to be feasible, otherwise intensive io holding pages would deny user wiring requests.

That is my next step, yes. I am not certain that the changes must be committed together since the user wire limit is already quite broken: it is typically exceeded for anyone using the ZFS ARC, and mlockall() does not check the user wire limit.

My point is that it might start breaking configurations which worked before, e.g. UFS/tmpfs-only installs.

In D19247#413465, @kib wrote:

Don't we need to split the kernel wire/user wire limits for this to be feasible, otherwise intensive io holding pages would deny user wiring requests.

What are the semantics on Linux? I can imagine O_NONBLOCK meaning "return EAGAIN if the page is swapped out," in which case this patch is not sufficient.

In D19337#413816, @jeff wrote:

We probably shouldn't enable NUMA on 32 bit platforms. It doesn't make a ton of sense.

Ping?

In D19265#413165, @cem wrote:

Thanks for taking a look!

In D19265#413098, @markj wrote:

I think the dtrace changes are somewhat hackish.

Yes, that's a fair characterization. (I think it kind of fits in with the quality and design of the rest of fbt, but...)

I think the dtrace changes are somewhat hackish. Did you consider the approach of modifying the D compiler to shift argument indices accordingly when one of a probes arguments is a CONSTVAL?

Overall this looks ok to me.

In D18848#413071, @markj wrote:

Note, Dwarf_Locdesc is part of the public ABI, so this change would require a library version number bump; see SHLIB_MAJOR in lib/libdwarf/Makefile.

Did you consider adding a len field to Dwarf_Loc instead? Consumers can easily sum up the expressions for a given description and add the fixed dwarf_get_address_size(dbg) + 2.

Note, Dwarf_Locdesc is part of the public ABI, so this change would require a library version number bump; see SHLIB_MAJOR in lib/libdwarf/Makefile.

Looks ok to me, modulo a couple more style nits.

Make a comment more accurate.

In D19273#412540, @cem wrote:

In D19273#412458, @markj wrote:

Solve the race using a per-process generation counter which gets updated
before a tracepoint is removed from the hash table, and after it is
removed from the target process' vmspace.

We do the latter, but I think we're missing the former.