Hi, I have a simple question about TLB entries. If you need to memory map area larger than page size does netbsd kernel allocate one tlb entry to describe entire area or multiple entries describing several pages of page size each? Regards, Alex
"Alex Pelts" wrote: > I have a simple question about TLB entries. If you need to memory map > area larger than page size does netbsd kernel allocate one tlb entry to > describe entire area or multiple entries describing several pages of > page size each? NetBSD only ever uses 4kB pages. If you're talking about non-KSEG0/1 kernel areas, using larger pages shouldn't be an overly difficult project... Simon.
On Fri, Dec 15, 2006 at 02:13:36PM +1100, Simon Burge wrote: > If you're talking about non-KSEG0/1 kernel areas, using larger pages > shouldn't be an overly difficult project... If you go there, just remember to update pmap_extract() so it can deal with your new kind of mappings. Martin
simonb <at> NetBSD.org wrote: > "Alex Pelts" wrote: > > > I have a simple question about TLB entries. If you need to memory map > > area larger than page size does netbsd kernel allocate one tlb entry to > > describe entire area or multiple entries describing several pages of > > page size each? > > NetBSD only ever uses 4kB pages. > > If you're talking about non-KSEG0/1 kernel areas, using larger pages > shouldn't be an overly difficult project... How about sys/arch/mips/mips/wired_map.c? (used by arc and ews4800mips etc. to map framebuffer VRAM) --- Izumi Tsutsui
Izumi Tsutsui wrote: > simonb <at> NetBSD.org wrote: > > > "Alex Pelts" wrote: > > > > > I have a simple question about TLB entries. If you need to memory map > > > area larger than page size does netbsd kernel allocate one tlb entry to > > > describe entire area or multiple entries describing several pages of > > > page size each? > > > > NetBSD only ever uses 4kB pages. > > > > If you're talking about non-KSEG0/1 kernel areas, using larger pages > > shouldn't be an overly difficult project... > > How about sys/arch/mips/mips/wired_map.c? > (used by arc and ews4800mips etc. to map framebuffer VRAM) I'm not sure that wired TLB entries are the answer, although I haven't measured this on MIPS yet. See http://mail-index.netbsd.org/port-powerpc/2006/10/27/0000.html for the impact of wired TLBs on 405 PowerPC. The quick summary is that overall the system got a lot more TLB misses as the number of available (non-wired) TLBs decreases, even where those wired TLBs were for some often accessed resources (system RAM in this case). Instrumenting on MIPS will be a little more difficult, since the PowerPC tlb miss handler didn't need to squeeze in to 32 instructions. I'd(Continue reading)
Thank you all for your replies. I was not actually going to change anything. I was just curious how it works. We had a discussion at work about this. If one needs to mmap a large area say to access device but the page size is 4K and each TLB entry describes 1 page we were discussing how big is overhead of page faults when accessing large memory area because of limited number of processor tlb entries. Regards, Alex Simon Burge wrote: > Izumi Tsutsui wrote: > >> simonb <at> NetBSD.org wrote: >> >>> "Alex Pelts" wrote: >>> >>>> I have a simple question about TLB entries. If you need to memory map >>>> area larger than page size does netbsd kernel allocate one tlb entry to >>>> describe entire area or multiple entries describing several pages of >>>> page size each? >>> NetBSD only ever uses 4kB pages. >>> >>> If you're talking about non-KSEG0/1 kernel areas, using larger pages >>> shouldn't be an overly difficult project... >> How about sys/arch/mips/mips/wired_map.c? >> (used by arc and ews4800mips etc. to map framebuffer VRAM) > > I'm not sure that wired TLB entries are the answer, although I haven't > measured this on MIPS yet.(Continue reading)
I recently noticed that ddb had no symbols on my sgimips (O2) machine - so
I started looking for the missing things. After fixing the bootloader to
pass them, I now have symbols, and /dev/ksyms works fine.
But, to my suprise, ddb backtrace does not show names:
Stopped at netbsd:cpu_Debugger+0x4: jr ra
bdslot: nop
db> bt
803bb96c+898 (ff00,bf390000,5,400) ra 80182084 sz 0
80181a98+5ec (ff00,bf390000,5,400) ra 0 sz 0
User-level: curlwp NULL
db> c
So ddb knows where I stopped it, but the backtrace does not display symbols.
I looked around the source and beside a DDB_TRACE symbol never defined
anywhere in our source tree I did not find any hints.
Is mips ddb support just incomplete (this is how it looks to me), or did I
do something sgimips specific wrong?
Martin
RSS Feed2 | |
|---|---|
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 |
