• Add PNP info to PCI attachment of ismt driver

• Update PNP info to PCI attachment of ignore driver

Please include root cause / explanations in the commit log message as well.

In D15560#338076, @cem wrote:

In D15560#337979, @markj 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.

In D15977#338278, @kib wrote:

In D15977#338276, @jeff wrote:

The other thing to consider is how accurate it needs to be and already is. Which thread was scheduled in the last tick is just as arbitrary as this LRU. You just want to replace something that hasn't been used in a long time. I would guess we're more often looking at things that haven't been touched in seconds or at least hundreds of milliseconds than within a few ticks. I can measure that but it will of course be grossly dependent on the workload and amount of memory.

If we do not need an LRU, might be we do not need the partpopq list at all ? E.g. keeping a bins of generations per ticks, up to some limited number of bins.

In D15977#338276, @jeff wrote:

The other thing to consider is how accurate it needs to be and already is. Which thread was scheduled in the last tick is just as arbitrary as this LRU. You just want to replace something that hasn't been used in a long time. I would guess we're more often looking at things that haven't been touched in seconds or at least hundreds of milliseconds than within a few ticks. I can measure that but it will of course be grossly dependent on the workload and amount of memory.

In D15977#338275, @kib wrote:

How much random becomes the order of the partpopq ? Is there any way to evaluate it ?

I mean, a tick is a lot, so instead of only doing it at tick, deletegate the limited (?) sorting of the rvq_partpop queues by lasttick to a daemon.

How much random becomes the order of the partpopq ? Is there any way to evaluate it ?

Some great stuff in here. Let's peel off parts while we perfect the rest.

Could you update the diff making you the maintainer of the whole transmission-suite?

After two iterations of buildworld the debug.foo output is

foo: 39074413 14698168 5130471 1754002 592517 134527 38946 17422 0 0 0 0 0
calls avoided: 60091879

To be clear, I don't intend to commit the sysctl with the patch.

Looks good.

Changes according to the inline comments

Remove -1 from strlcat() in shm_inlink_success test case

Great work tracking this down!

This idea courtesy of ian@:

Make MIPS machine/vm.h usable.
Fix gcc 32bit arches.

In D15814#338185, @brooks wrote:

In D15814#337257, @kib wrote:

You can create symbols which are exported but not linkable, since they do not provide a default version. Such symbol can be only created by asm '@' syntax, it should be removed from the version map. Also I do not see a sense in leaving the private symbols around.

Is there an example of this?

In D15814#337257, @kib wrote:

You can create symbols which are exported but not linkable, since they do not provide a default version. Such symbol can be only created by asm '@' syntax, it should be removed from the version map. Also I do not see a sense in leaving the private symbols around.