hi, > On Thu, Nov 25, 2010 at 04:18:25AM +0000, YAMAMOTO Takashi wrote: >> hi, >> >> > Hi, thanks for review. >> > >> > On Thu, Nov 25, 2010 at 01:58:04AM +0000, YAMAMOTO Takashi wrote: >> >> hi, >> >> >> >> - what's VM_PHYSSEG_OP_PG? >> > >> > It's to lookup vm_physseg by "struct vm_page *", relying on that >> > "struct vm_page *[]" is allocated linearly. It'll be used to remove >> > vm_page::phys_addr as we talked some time ago. >> >> i'm not sure if commiting this unused uncommented code now helps it. >> some try-and-benchmark cycles might be necessary given that >> vm_page <-> paddr conversion could be performace critical. > > If you really care performance, we can directly pass "struct vm_page > *" to pmap_enter(). > > We're doing "struct vm_page *" -> "paddr_t" just before pmap_enter(), > then doing "paddr_t" -> "vm_physseg" reverse lookup again in > pmap_enter() to check if a given PA is managed. What is really > needed here is, to lookup "struct vm_page *" -> "vm_physseg" once > and you'll know both paddr_t and managed or not.
i agree that the current code is not ideal in that respect. otoh, i'm not sure if passing vm_physseg around is a good idea. YAMAMOTO Takashi > >> >> YAMAMOTO Takashi > > -- > Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635
