An Atm card containing $2.8 m,contract/inheritance have been awarded to you send your details to atmdelivery009 <at> sify.com Telephone number:+2347036427331 Mr.Johnson Paul. Sincerely,Atm Card Award Team.
pmap_remove_pv() copies PV_MODIFIED | PV_REFERENCED bits set in
pv_flags. I don't think that this happens now that PV_MODIFIED and
PV_REFERENCED bits are only set in pvh_attrs because these are per
physical page property, not per virtual map (pv_entry). This coded
was added in 1.75, at that time pvh_attrs didn't exist. I guess that
pv_flags in the first pv_entry was used as what pvh_attrs does (== per
physical page property).
I think that the following lines could be removed safely.
1.75 mhitch 2047: /*
2048: * Copy current
modified and referenced status to
2049: * the following entry
before copying.
2050: */
1.130 chs 2051:
1.75 mhitch 2052: npv->pv_flags |=
2053: pv->pv_flags &
(PV_MODIFIED | PV_REFERENCED);
I have not tested at all. :)))
Masao
uebayasi <at> gmail.com wrote: > pmap_remove_pv() copies PV_MODIFIED | PV_REFERENCED bits set in > pv_flags. I don't think that this happens now that PV_MODIFIED and > PV_REFERENCED bits are only set in pvh_attrs because these are per > physical page property, not per virtual map (pv_entry). This coded > was added in 1.75, at that time pvh_attrs didn't exist. I guess that > pv_flags in the first pv_entry was used as what pvh_attrs does (== per > physical page property). > > I think that the following lines could be removed safely. > > 1.75 mhitch 2047: /* > 2048: * Copy current > modified and referenced status to > 2049: * the following entry > before copying. > 2050: */ > 1.130 chs 2051: > 1.75 mhitch 2052: npv->pv_flags |= > 2053: pv->pv_flags & > (PV_MODIFIED | PV_REFERENCED); > > I have not tested at all. :))) I'm not sure what's your point and how exactly you tracked the logs, but are you asking that code block should have been removed in rev 1.163? --- Izumi Tsutsui(Continue reading)
> I'm not sure what's your point and how exactly you tracked the logs, > but are you asking that code block should have been removed in rev 1.163? I have not tracked all the changes. My question is just "when PV_MODIFIED and/or PV_REFERENCED are set in pv_flags"? Masao
After re-reading logs, I think that 1.163 was the right timing to remove the code fragment, yes. PV_MODIFIED / PV_REFERENCED are never set in pv_flags now. Probably it'd be better to rename these to PVH_*? Masao
> I think that the word "Flash the TLB" used in comments is a little
> confusing. "Invalidate the TLB" would be more appropriate.
It is not flash but flush, and the latter has almost
the same meaning with invalidate, I think.
("grep -i flush src/sys/arch/*/*/pmap.c" gets many lines)
Sometimes "flush" implicitly means "invalidate and writeback"
(against "purge" which is invalidate only) for memory cache ops,
but there is no writeback ops on TLB, I guess.
---
Izumi Tsutsui
> > I'm not sure what's your point and how exactly you tracked the logs, > > but are you asking that code block should have been removed in rev 1.163? > > I have not tracked all the changes. My question is just "when > PV_MODIFIED and/or PV_REFERENCED are set in pv_flags"? The answer is: "Those page attributes have been moved from pv_flags in pv_entry (which belonged to pmap_physseg) to pvh_attr in vm_page_md in rev 1.163." (we could track it by checking when pvh_attr was in vmparam.h) In that revision my intention was to just remove gcc extention (it was suggetted by Jason to move stuff from physseg to vm_page), but anyway I'll remove that code block and rename those page attributes to PGA_FOO like alpha for future readers. --- Izumi Tsutsui
> The answer is: > "Those page attributes have been moved from pv_flags in pv_entry > (which belonged to pmap_physseg) to pvh_attr in vm_page_md in rev 1.163." > (we could track it by checking when pvh_attr was in vmparam.h) > > In that revision my intention was to just remove gcc extention > (it was suggetted by Jason to move stuff from physseg to vm_page), > but anyway I'll remove that code block and rename those page attributes > to PGA_FOO like alpha for future readers. Thanks! Masao
Back on Mon, Mar 16, 2009 at 07:54:56PM +0900, Toru Nishimura wrote: > Does anyone out here have connection w/ Sicortex and have > ambition to port NetBSD for it? The company looks ex-Digital > found at the historic site. Use NetBSD instead ... Sicortex has since collapsed :( I suspect that people who own the h/w will be wanting to keep it for a while yet, and thus perhaps wanting a maintained OS; however, I have no idea how to translate that into rescuing hardware docs from the corporate implosion. -- -- David A. Holland dholland <at> netbsd.org
RSS Feed1 | |
|---|---|
3 | |
4 | |
2 | |
3 | |
6 | |
4 | |
13 | |
2 | |
8 | |
1 | |
2 | |
1 | |
3 | |
2 | |
30 | |
1 | |
7 | |
9 | |
11 | |
11 | |
14 | |
10 | |
5 | |
8 | |
3 | |
1 | |
42 | |
13 | |
4 | |
7 | |
4 | |
17 | |
17 | |
7 | |
1 | |
6 | |
16 | |
22 | |
9 | |
5 | |
6 | |
32 | |
2 | |
2 | |
9 | |
3 | |
5 | |
2 | |
3 | |
1 | |
9 | |
5 | |
2 | |
3 | |
23 | |
5 | |
1 | |
10 | |
23 | |
10 | |
31 | |
39 | |
6 | |
5 | |
9 | |
7 | |
7 | |
1 | |
41 | |
36 | |
10 | |
24 | |
12 | |
4 | |
23 | |
8 | |
28 | |
24 | |
66 | |
48 | |
24 | |
4 | |
2 | |
3 | |
3 | |
7 | |
79 | |
36 | |
5 | |
6 | |
23 | |
2 | |
20 | |
15 | |
8 | |
16 | |
37 | |
22 | |
44 | |
18 | |
5 | |
39 | |
13 | |
70 | |
26 | |
7 | |
1 | |
10 | |
15 | |
25 | |
2 | |
8 | |
10 | |
5 |
