First, I am not sure that this change is enough. Ideally, the consistency would be kept between the buffer cache state and vnode object as well, so e.g. it is impossible to observe a buffer with b_lblkno outside of the v_object size. This is true for other filesystems but not for NFS.

How hard would be assert that lf is a dso, as opposed to an object file ?

I think the only interesting case is pmap_mapbios(), but it should be fine. Anyway, we will see.

Latest round of fixes.

Hm, having something like quiesce is useful. I understand your observation about the idle threads. But then we should create a highest-priority interrupt thread that gets bound to all cpus sequentially and provide the service.

Is there any use of PGA_WRITEABLE flag left after the patch ? pmap_page_is_write_mapped() takes the pv lock, while PGA_WRITEABLE check is essentially free.

We have MAP_NOSYNC flag for mmap(2). Suppose we have one mapping with the flag set, and other with the flag clear. Then write fault for the page might come from either mappings, and we either want or not want to set VPO_NOSYNC depending from which mapping the write fault is coming. More, if the VPO_NOSYNC page is re-dirtied from non-NOSYNC mapping, we want to remove VPO_NOSYNC.

What do you mean by a note that pageout clears valid state of the page ? I thought that pageout laundries the page, and a clean page might be freed for reuse. In other words, valid bits can be only trimmed by truncation either of the vnode or swap backing OBJ_NOSPLIT object.

In D21458#474367, @sef wrote:

Any further comments on this? I'd gotten an OOB message from Josh about this. If not, I'll make sure it's still functional and plan on committing this weekend or Monday.

Any further comments on the change ?

In D21592#473571, @jeff wrote:

In D21592#473568, @markj wrote:

I think I've brought this up before, but I would like it if the VM had a generic per-2MB page structure. We already have several in vm_reserv and the pmap, and IMO it would be a good place to maintain a "compound" busy state, rather than in the object. I worry that a mechanism to block the busying of all pages in an object will inhibit concurrency and lead to transient latency spikes. I don't object to the current approach though.

Right now the object lock is the mechanism that blocks busying of all pages and creates transient latency spikes. This at least narrows it a level and allows other object operations to proceed. If you had a per-superpage object you would have to be able to very quickly look it up and acquire in tryxbusy/sbusy.

Ultimately I would like to see a generic mechanism that can treat pages as groups with a single set of state. A variable page size.

This looks fine to me, but I have no idea why John put PCI_RES_BUS under #ifdef NEW_PCIB instead of defining it always. Also, would it be reasonable to do a separate pass to rename PCI_RES_BUS to SYS_RES_PCIBUS ?

I think it would be fair to remove copyrights from machine/resource.h, instead put the trivial header files into public domain or assign to yourself.

I think it is fine.

In D21667#472964, @mjg wrote:

I think it's cleaner to handle this separately mostly because this function cannot do any clean up so it behaves quite differently compared to vn_start_write. If you insist I can fold it in.

Why do you need vn_start_write_nb() when vn_start_write() already takes the flag argument ?

In D21678#472744, @mjg wrote:

In D21642#472677, @markj wrote:

In D21642#472503, @alc wrote:

Yes, I put the const in the wrong place. So, code within vm_page.c will avoid the dereference, but code outside vm_page.c that uses the declaration from vm_page.h will still perform the dereference. Declaring vm_page_array as an array would deal with both cases.

I'm still missing something. vm_page_array cannot be defined in vm_page.h, and if it is not defined there I do not see how the compiler can elide a memory dereference.

It cannot be defined, but can be declared, same as now. Or I do not understand what you are trying to say.

This is not yet updated to pcpu counters, right ?