- User Since
- Jun 4 2014, 10:38 AM (279 w, 5 d)
Fri, Oct 11
- add VI_TRYLOCK_CONTENDED
- reclaim chunks from all domains
This would be a NOP in this workload. I see I did not mention in this review, but the setup is as follows: there are n worker jails, each with a tmpfs-based world. Each jail comes with a cpuset binding it to only one domain and tmpfs itself is populated while bound to said domain.
- simplify pc_to_domain
- when initializing lists go for PMAP_MEMDOM instead of looping
- fix the comment about initializing pmap pv chunk list
Thu, Oct 10
Tue, Oct 8
- drop cld for i386
system time is reduced, but user time is increased. In the current state there is no win and it's probably a pessimization due to increased memory traffic (as in, it's going to probably hurt more involved workloads). However, the result may be distorted by current bottlenecks (mostly vm object handling), which is why I think this needs to be reevaluated after this stuff gets fixed.
This struct should start getting cached, which will have a side effect of not wandering to the minidump array this often.
Mon, Oct 7
Sun, Oct 6
Booting on packet.net has failed, I did not investigate. cperciva gave me a box to play with in ec2 instead.
Turns out there is a bug with in handling of nullfs and unionfs. Their routines may end up taking the interlock. Taking care of nullfs is easy, but unionfs requires a little more work.
- assert (sizeof(*pvd) == 64)
- change non-superpage i type to long
This can be modified to use CK_* macros which make it safe to traverse in face of modification performed at the same time. Then this can only be a problem if the list gets corrupted and that's what we have to traverse. Should this be of concern, pv chunk can grow a 'magic' field to verify the next element is of the right type. This still can run into loops, which again can be handled in at least two ways: either stop the traversal after n entries or maintain a global counter (per-cpu based).
Sat, Oct 5
- add missing support for sigdefer ops
- add _set routine and use it in nfs and devfs
- change several vars to long type
- assert PA within the range
i386 has a lot of cld already and I have no means to test the removal. I can plug them from the places modified by this patch though.
- add the missing pvd->pv_invl_gen = 0;
- keep the old code when VN_RESERVLEVEL == 0
- allocate the area using kva_alloc. inserting pages with kmem_back_domain gives me a panic: vm_reserv_alloc_page: domain mismatch, which looks like a bug elsewhere and it may be worth fixing regardless of this patch
- bump pmap_large_md_page to 64 bytes. I was somehow convinced md_page is 16 bytes, but it turned out to be 24. Adding the lock makes it 56. I added in invl gen counter as well (since it does have superpage granularity anyway) which makes it 64 bytes in total. Makes for a little simpler code and slight bump in performance.
Wed, Oct 2
Looks like the current code (i.e., unpatched) is already buggy in this regard.
Tue, Oct 1
I think this looks fine, but would preferable take care of all ports which are currently missing these atomics. There are reviews pending for powerpc and arm but they seem a little stalled. Thus the proposed solution is to just add this for everyone and let maintainers remove it as they provide their own version.
Mon, Sep 30
Sun, Sep 29
Sat, Sep 28
- chunklist -> pv_chunklist
- free_chunk -> free_chunks
Fri, Sep 27
Thu, Sep 26
It is wrapped around the current code on purpose - provides all expected win the common case, is easy to opt in and requires no changes for filesystems which don't participate. But more importantly I consider it to be a temporary bandaid until interaction of lookup and the namecache is reworked so that there is no need to VFS_ROOT or busy in the common case.
Tue, Sep 24
The new op is *not* called by anything but the new handler which has to be explicitly set by filesystems which want the feature, i.e. the change is a no-op for anyone who does not opt in.
I have a separate patch for zfs since it involves reverting its current support, which would only clutter this review.
- drop the curcpu check, it is of no essence
- add a comment explaining the loop
- reindent cpus_fence_seq_cst
So is this waiting on anyone in particular? I'm not qualified to review the arm variants and most definitely should not be added as a reviewer.
How about atomic_util.h then?