markj (Mark Johnston)
User

Projects

User Details

User Since
Mar 12 2014, 1:00 AM (223 w, 4 d)

Recent Activity

Today

markj accepted D15989: vm: stop passing M_ZERO when allocating radix nodes.

I would add a debug-only dtor which verifies that the child pointers are zeroed.

Sun, Jun 24, 12:38 PM

Yesterday

markj updated the test plan for D15980: Ensure that all queue state is cleared when vm_page_dequeue() returns..
Sat, Jun 23, 12:20 PM
markj created D15980: Ensure that all queue state is cleared when vm_page_dequeue() returns..
Sat, Jun 23, 12:17 PM
markj accepted D15976: Change vm_page_import() to avoid physical memory fragmentation.
Sat, Jun 23, 11:03 AM
markj added a comment to D15560: Use a spin lock to serialize updates on AMD CPUs..
In D15560#338076, @cem wrote:

Apologies for the delay. Would anyone with a Ryzen or TR be able to test a microcode update with the updated patch applied?

I'd be able to if AMD has published any microcode updates for Ryzen/TR. It seems the ones they distribute through non-BIOS channels are just for Epyc.

Sat, Jun 23, 10:49 AM
markj committed rS335580: Re-count available PV entries after reclaiming a PV chunk..
Re-count available PV entries after reclaiming a PV chunk.
Sat, Jun 23, 10:42 AM
markj closed D15911: Re-count available PV entries after allocating a new chunk..
Sat, Jun 23, 10:42 AM
markj added inline comments to D15977: Make the partpopq LRU sloppy to reduce contention.
Sat, Jun 23, 10:30 AM

Fri, Jun 22

markj added a comment to D15910: Avoid reclaiming the PV entry for a VA when updating the VA's PTE..

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

Fri, Jun 22, 5:13 PM
markj added a comment to D15910: Avoid reclaiming the PV entry for a VA when updating the VA's PTE..
In D15910#338067, @alc wrote:
In D15910#337632, @kib wrote:
In D15910#337582, @alc wrote:
  1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

Can you elaborate more, please ? What do you mean by destroying the old mapping ? In particular, do you mean installing the pte with clear PG_V into the changing PTE ?

Yes, I mean destroying the PTE, including TLB shootdown. In effect, briefly the PTE will be 0. Then, installing the new PTE is just a pte_store(). All of the stuff that we currently perform under "if ((origpte & PG_V) != 0) {" will already have been performed when we destroyed the PTE.

Fri, Jun 22, 5:11 PM
markj updated the diff for D15911: Re-count available PV entries after allocating a new chunk..
  • Only set "reclaimed" once when executing the loop.
  • Fix the problem in the arm64 pmap code.
Fri, Jun 22, 10:50 AM
markj added a comment to D15560: Use a spin lock to serialize updates on AMD CPUs..

Apologies for the delay. Would anyone with a Ryzen or TR be able to test a microcode update with the updated patch applied?

Fri, Jun 22, 10:28 AM
markj updated the diff for D15560: Use a spin lock to serialize updates on AMD CPUs..

Only update microcode on physical CPUs.

Fri, Jun 22, 10:27 AM

Thu, Jun 21

markj added inline comments to D15911: Re-count available PV entries after allocating a new chunk..
Thu, Jun 21, 5:12 PM
markj added a comment to D15911: Re-count available PV entries after allocating a new chunk..

I note that arm64 has this bug as well. I'll fix that identically if the current diff is ok.

Thu, Jun 21, 4:44 PM
markj updated the diff for D15911: Re-count available PV entries after allocating a new chunk..
  • Only recount after a reclaim.
Thu, Jun 21, 4:43 PM
markj added a comment to D15910: Avoid reclaiming the PV entry for a VA when updating the VA's PTE..
In D15910#337582, @alc wrote:

I have two comments.

  1. The change to reserve_pv_entries() is unnecessary. That function is only called during demotion. At that point, the only PV entry will be for the superpage mapping, and reclaim_pv_chunk() already skips superpage mappings.
Thu, Jun 21, 4:21 PM

Tue, Jun 19

markj added a comment to D15911: Re-count available PV entries after allocating a new chunk..
In D15911#336659, @kib wrote:

This should be fine.

Can we return an indicator if the page freed from the locked pmap, and retry only in this case ?

Tue, Jun 19, 11:43 PM
markj added a comment to D15560: Use a spin lock to serialize updates on AMD CPUs..

bump. @markj Did you want to shovel this into head?

Tue, Jun 19, 9:22 PM
markj updated the test plan for D15911: Re-count available PV entries after allocating a new chunk..
Tue, Jun 19, 7:51 PM
markj updated the summary of D15910: Avoid reclaiming the PV entry for a VA when updating the VA's PTE..
Tue, Jun 19, 7:50 PM
markj created D15911: Re-count available PV entries after allocating a new chunk..
Tue, Jun 19, 7:45 PM
markj created D15910: Avoid reclaiming the PV entry for a VA when updating the VA's PTE..
Tue, Jun 19, 7:44 PM

Mon, Jun 18

markj accepted D15879: sysutils/DTraceToolkit: remove missing providers in FreeBSD 12.0-CURRRENT.

I'll admit that I've never seen any reason to prefer dtruss to truss(1).

Mon, Jun 18, 11:04 AM

Sat, Jun 16

markj accepted D15855: Fix dtrace output of IP addresses as strings.
Sat, Jun 16, 6:04 PM

Fri, Jun 15

markj accepted D15829: Retain offset compatibility with pre-12.0 dumps.

I think this is fine. The panic string buffer is bigger than it needs to be.

Fri, Jun 15, 6:51 PM
markj committed rS335191: MFC r334506:.
MFC r334506:
Fri, Jun 15, 8:59 AM

Wed, Jun 13

markj accepted D15293: Handle the race between fork/vm_object_split() and faults..
Wed, Jun 13, 4:54 PM
markj accepted D15691: Make kernel allocations be non-executable on some platforms.
Wed, Jun 13, 4:47 PM
markj added inline comments to D15765: fallback to soreceive_generic in soreceive_stream for cases not handled correctly currently.
Wed, Jun 13, 4:46 PM
markj added inline comments to D15691: Make kernel allocations be non-executable on some platforms.
Wed, Jun 13, 4:45 PM
markj added inline comments to D15691: Make kernel allocations be non-executable on some platforms.
Wed, Jun 13, 4:35 PM
markj accepted D15691: Make kernel allocations be non-executable on some platforms.
Wed, Jun 13, 4:28 PM

Mon, Jun 11

markj committed rS334961: Process CUs with a language attribute of DW_LANG_Mips_Assembler..
Process CUs with a language attribute of DW_LANG_Mips_Assembler.
Mon, Jun 11, 4:33 PM
markj committed rS334959: Use the cached curthread reference in pmc_process_interrupt()..
Use the cached curthread reference in pmc_process_interrupt().
Mon, Jun 11, 4:27 PM
markj committed rS334956: MFC r334505:.
MFC r334505:
Mon, Jun 11, 3:45 PM
markj committed rS334955: MFC r334504:.
MFC r334504:
Mon, Jun 11, 3:44 PM
markj committed rS334954: MFC r334101:.
MFC r334101:
Mon, Jun 11, 3:43 PM
markj added a comment to D15749: Ensure that the pageout daemon runs on schedule.

Regarding the testing section, after running pgbench in a loop for roughly 12 hours, I see:

Mon, Jun 11, 3:16 PM

Sun, Jun 10

markj accepted D15733: Fix build of bxe with base gcc on i386.
Sun, Jun 10, 2:07 PM

Sat, Jun 9

markj committed rD51809: Document the __FreeBSD_version bump to 1200067..
Document the __FreeBSD_version bump to 1200067.
Sat, Jun 9, 8:25 PM
markj committed rS334892: Bump __FreeBSD_version after r334881 and force libdwarf to be rebuilt..
Bump __FreeBSD_version after r334881 and force libdwarf to be rebuilt.
Sat, Jun 9, 8:01 PM
markj committed rS334890: Tell the compiler that rdtscp clobbers %ecx..
Tell the compiler that rdtscp clobbers %ecx.
Sat, Jun 9, 6:31 PM
markj committed rS334883: Don't process DWARF generated from non-C/C++ code..
Don't process DWARF generated from non-C/C++ code.
Sat, Jun 9, 3:11 PM
markj closed D15712: Add DW_LANG_* definitions from DWARF 4 and 5..
Sat, Jun 9, 2:51 PM
markj committed rS334881: Add DW_LANG_* definitions from DWARF 4 and 5..
Add DW_LANG_* definitions from DWARF 4 and 5.
Sat, Jun 9, 2:51 PM
markj added a reviewer for D15712: Add DW_LANG_* definitions from DWARF 4 and 5.: emaste.
Sat, Jun 9, 3:03 AM
markj created D15712: Add DW_LANG_* definitions from DWARF 4 and 5..
Sat, Jun 9, 3:01 AM

Fri, Jun 8

markj committed rS334846: Correct the list of supported drivers..
Correct the list of supported drivers.
Fri, Jun 8, 5:55 PM

Thu, Jun 7

markj accepted D15691: Make kernel allocations be non-executable on some platforms.
Thu, Jun 7, 5:13 PM

Wed, Jun 6

markj committed rS334697: MFC r334389:.
MFC r334389:
Wed, Jun 6, 1:00 AM

Tue, Jun 5

markj committed rS334653: Don't build brk_test on platforms that don't support brk()..
Don't build brk_test on platforms that don't support brk().
Tue, Jun 5, 1:06 PM

Mon, Jun 4

markj committed rS334627: Regen after r334626..
Regen after r334626.
Mon, Jun 4, 7:37 PM
markj committed rS334626: Reimplement brk() and sbrk() to avoid the use of _end..
Reimplement brk() and sbrk() to avoid the use of _end.
Mon, Jun 4, 7:35 PM
markj closed D15663: Rewrite brk()/sbrk() to avoid using _end..
Mon, Jun 4, 7:35 PM
markj updated the diff for D15663: Rewrite brk()/sbrk() to avoid using _end..
  • Address some review feedback.
Mon, Jun 4, 5:23 PM
markj added inline comments to D15663: Rewrite brk()/sbrk() to avoid using _end..
Mon, Jun 4, 5:16 PM
markj committed rS334622: Correct the description of vm_pageout_scan_inactive() after r334508..
Correct the description of vm_pageout_scan_inactive() after r334508.
Mon, Jun 4, 4:47 PM
markj committed rS334616: Fix the NUMA build for non-x86 platforms..
Fix the NUMA build for non-x86 platforms.
Mon, Jun 4, 2:56 PM
markj committed rS334614: MFC r319792:.
MFC r319792:
Mon, Jun 4, 2:23 PM
markj committed rS334613: MFC r333570:.
MFC r333570:
Mon, Jun 4, 2:16 PM
markj committed rS334612: MFC r334100:.
MFC r334100:
Mon, Jun 4, 2:15 PM
markj committed rS334611: MFC r333278, r333279:.
MFC r333278, r333279:
Mon, Jun 4, 2:13 PM
markj updated the test plan for D15663: Rewrite brk()/sbrk() to avoid using _end..
Mon, Jun 4, 2:11 PM
markj updated the diff for D15663: Rewrite brk()/sbrk() to avoid using _end..
  • Remove brk.S from MDASM in a couple more places.
Mon, Jun 4, 2:08 PM
markj updated the test plan for D15663: Rewrite brk()/sbrk() to avoid using _end..
Mon, Jun 4, 2:06 PM
markj created D15663: Rewrite brk()/sbrk() to avoid using _end..
Mon, Jun 4, 2:03 PM

Sun, Jun 3

markj added inline comments to D15491: Eliminate the "pass" variable in the page daemon control loop..
Sun, Jun 3, 4:43 PM

Sat, Jun 2

markj committed rS334508: Remove the "pass" variable from the page daemon control loop..
Remove the "pass" variable from the page daemon control loop.
Sat, Jun 2, 12:01 AM
markj closed D15491: Eliminate the "pass" variable in the page daemon control loop..
Sat, Jun 2, 12:01 AM

Fri, Jun 1

markj committed rS334506: Avoid completing I/O when dumping core after a panic..
Avoid completing I/O when dumping core after a panic.
Fri, Jun 1, 11:49 PM
markj closed D15592: Avoid completing non-dump I/O requests after a panic..
Fri, Jun 1, 11:49 PM
markj committed rS334505: Don't export _end on arm64 and riscv..
Don't export _end on arm64 and riscv.
Fri, Jun 1, 11:42 PM
markj committed rS334504: Remove an inaccuracy from mincore.2..
Remove an inaccuracy from mincore.2.
Fri, Jun 1, 11:41 PM
markj updated the diff for D15592: Avoid completing non-dump I/O requests after a panic..

Check for non-dump I/O in biodone() instead.

Fri, Jun 1, 1:37 AM

Thu, May 31

markj added a comment to D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
In D15607#330348, @cem wrote:
In D15607#330347, @jhb wrote:

I do think it was intentional to truncate once the output buffer was exhausted rather than failing with ENOMEM. Its debatable if that is a useful thing or not. Most sysctls return ENOMEM instead so that the request can be retried with a larger output buffer so it is probably better to do what this does.

That makes sense in sysctl context. I'm not sure it makes sense in core dump context. Maybe it does, but it would probably require additional changes there.

Thu, May 31, 10:33 PM

Wed, May 30

markj committed rS334389: Typo..
Typo.
Wed, May 30, 4:49 PM
markj added a comment to D15592: Avoid completing non-dump I/O requests after a panic..
In D15592#329715, @imp wrote:

So I'm still uneasy about this.

Why are we doing this at the lowest levels? Some of the CCBs that might be completed are for components that are fine during a dump. This is an upper layer problem, not a CAM problem. Wouldn't it make more sense to do this in biodone or bufdone? That way we don't have to worry about tagging every last little thing with CAM_CCB_DUMP that needs it. Since we're doing the dump, that won't go through the upper layers at all. If we put the block at the entry to geom, or the exit from geom, that would accomplish the same thing.

Wed, May 30, 3:20 AM

Tue, May 29

markj updated the diff for D15592: Avoid completing non-dump I/O requests after a panic..
  • Update the comment per imp's remark.
Tue, May 29, 9:38 PM
markj added inline comments to D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
Tue, May 29, 8:16 PM
markj updated the diff for D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
  • Use an if statement.
Tue, May 29, 8:15 PM
markj added a comment to D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
In D15607#329598, @cem wrote:

I don't see how this affects tmux in any way, unless the error code breaks the previously working-but-truncated path(s). If that's the case, I think those should be changed to swallow ENOMEM. But then, what's the point of propagating the error up?

Tue, May 29, 8:01 PM
markj updated the test plan for D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
Tue, May 29, 7:42 PM
markj updated the test plan for D15592: Avoid completing non-dump I/O requests after a panic..
Tue, May 29, 7:41 PM
markj created D15607: Improve error handling for KERN_PROC_{CWD,FILEDESC}..
Tue, May 29, 6:13 PM
markj committed rS334339: The extension for zstd-compressed files is ".zst"..
The extension for zstd-compressed files is ".zst".
Tue, May 29, 4:05 PM

Mon, May 28

markj updated the diff for D15592: Avoid completing non-dump I/O requests after a panic..
  • Fix nvme compilation; use sim_links linkage instead of periph_links.
Mon, May 28, 4:29 PM
markj added inline comments to D15592: Avoid completing non-dump I/O requests after a panic..
Mon, May 28, 4:28 PM
markj updated the diff for D15592: Avoid completing non-dump I/O requests after a panic..
  • Check "dumping" as well, in case kern.sync_on_panic is set.
Mon, May 28, 12:08 AM

Sun, May 27

markj updated the test plan for D15592: Avoid completing non-dump I/O requests after a panic..
Sun, May 27, 9:45 PM
markj created D15592: Avoid completing non-dump I/O requests after a panic..
Sun, May 27, 9:44 PM
markj abandoned D15591: Avoid completing non-dump I/O requests after a panic..
Sun, May 27, 9:39 PM
markj created D15591: Avoid completing non-dump I/O requests after a panic..
Sun, May 27, 9:38 PM

May 25 2018

markj added a comment to D15523: sysutils/devcpu-data: Update AMD microcode..

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

And send me the results of something like the following?

I get the same output, i.e., "CPU is not found in the equivalence table" for all files.

Can you post the detection output for your CPU? I assume you have a 17h here, but I'm not sure.

May 25 2018, 7:57 PM
markj committed rS334220: MFC r334050, r334051:.
MFC r334050, r334051:
May 25 2018, 7:16 PM
markj added a reviewer for D15574: cpucontrol: fix debugging for family on AMD cpus and add useful debugging.: avg.
May 25 2018, 5:18 PM

May 24 2018

markj added a comment to D15523: sysutils/devcpu-data: Update AMD microcode..

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

And send me the results of something like the following?

May 24 2018, 8:51 PM
markj committed rS334179: Update r334154 with review feedback from D15490..
Update r334154 with review feedback from D15490.
May 24 2018, 8:26 PM
markj added a comment to D15560: Use a spin lock to serialize updates on AMD CPUs..
In D15560#328520, @avg wrote:

@markj something like that, yes.
I am not sure if logical_cpus_mask is accurate on Ryzen, but I think that we collect enough topology information to either make it correct or to provide another way of checking whether a CPU is a "primary" thread of a core.

May 24 2018, 8:00 PM
markj added a comment to D15560: Use a spin lock to serialize updates on AMD CPUs..
In D15560#328515, @avg wrote:

I think that it should be relatively easy to instruct threads to do either an update or just a spin.
Having said that, I won't object against this change if it fixes a problem that has been experienced.

May 24 2018, 7:40 PM