Re: port-i386/37193 (x86 pmap concurrency strategy could use improvement)

[yamt%mwd.biglobe.ne.jp@localhost (YAMAMOTO Takashi)]

>  > +retry:
>  > +  mutex_spin_enter(&pvh->pvh_lock);
>  > +  while ((pve = SPLAY_MIN(pvtree, &pvh->pvh_root)) != NULL) {
>  > +          struct pmap *pmap = pve->pv_pmap;
>  > +          pt_entry_t *ptep;
>  > +          pt_entry_t opte;
>  >  
>  >            /* atomically save the old PTE and zap! it */
>  > -          opte = pmap_pte_testset(&ptes[pl1_i(pve->pv_va)], 0);
>  > -          KASSERT(pmap_valid_entry(opte));
>  > -          KDASSERT(pmap_pte2pa(opte) == VM_PAGE_TO_PHYS(pg));
>  > -
>  > -          if (opte & PG_W)
>  > -                  pve->pv_pmap->pm_stats.wired_count--;
>  > -          pve->pv_pmap->pm_stats.resident_count--;
>  > +          ptep = pmap_map_pte(pve->pv_ptp, pve->pv_va);
>  > +          do {
>  > +                  opte = *ptep;
>  > +                  if ((opte & (PG_FRAME | PG_V)) != expect) {
>  > +                          pmap_unmap_pte();
>  > +                          mutex_spin_exit(&pvh->pvh_lock);
>  > +                          x86_pause();
>  > +                          goto retry;
>  
>  This loop makes me suspicious. I need to look more closely but is there
>  any chance of a deadlock if the caller holds kernel_lock and a device
>  interrupt occurs on a CPU that we need to make progress?
>  
>  Thanks,
>  Andrew

you're right.  i made it drop kernel_lock around x86_pause().

YAMAMOTO Takashi