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

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR port-i386/37193; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-i386/37193 (x86 pmap concurrency strategy could use 
improvement)
Date: Thu, 10 Jan 2008 23:40:46 +0000

 On Thu, Jan 10, 2008 at 08:01:52PM +0900, YAMAMOTO Takashi wrote:
 
 > +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