On 23.01.2023 16:20, George Dunlap wrote:
> Re the original question: I've stared at the code for a bit now, and I
> can't see anything obviously wrong or dangerous about it.
>
> But it does make me ask, why do we need the "unpinning_l3" pseudo-argument
> at all? Is there any reason not to uncond
On Mon, Jan 23, 2023 at 8:41 AM Jan Beulich wrote:
> On 20.01.2023 18:02, George Dunlap wrote:
> > On Wed, Jan 11, 2023 at 1:52 PM Jan Beulich wrote:
> >
> >> Rather than doing a separate hash walk (and then even using the vCPU
> >> variant, which is to go away), do the up-pointer-clearing right
On 20.01.2023 18:02, George Dunlap wrote:
> On Wed, Jan 11, 2023 at 1:52 PM Jan Beulich wrote:
>
>> Rather than doing a separate hash walk (and then even using the vCPU
>> variant, which is to go away), do the up-pointer-clearing right in
>> sh_unpin(), as an alternative to the (now further limit
On Wed, Jan 11, 2023 at 1:52 PM Jan Beulich wrote:
> Rather than doing a separate hash walk (and then even using the vCPU
> variant, which is to go away), do the up-pointer-clearing right in
> sh_unpin(), as an alternative to the (now further limited) enlisting on
> a "free floating" list fragmen
On 11.01.2023 14:52, Jan Beulich wrote:
> Rather than doing a separate hash walk (and then even using the vCPU
> variant, which is to go away), do the up-pointer-clearing right in
> sh_unpin(), as an alternative to the (now further limited) enlisting on
> a "free floating" list fragment. This utili
Rather than doing a separate hash walk (and then even using the vCPU
variant, which is to go away), do the up-pointer-clearing right in
sh_unpin(), as an alternative to the (now further limited) enlisting on
a "free floating" list fragment. This utilizes the fact that such list
fragments are traver
