May be stupid question ;-)

May be stupid question ;-)

[Petko Manolov]

I'm wonder if its possible to have kernel code+data > 4M? So
pg0 won't be enough. And we have to init pg1. AFAIK the kernel don't
allocate more page tables for itself while in run. It sounds to me like
troubles in the future.  

	Petkan 
-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: May be stupid question ;-)

[Rik van Riel]

On Fri, 13 Nov 1998, Petko Manolov wrote:

> I'm wonder if its possible to have kernel code+data > 4M? 

Currently not, unless you compile in all sorts of useless
drivers (or you have a machine with 30+ different kinds of
extension cards)...

> So pg0 won't be enough. And we have to init pg1. AFAIK the kernel
> don't allocate more page tables for itself while in run. It sounds
> to me like troubles in the future. 

Most of the runtime tables are allocated after the memory
stuff has been taken care off. Then we have the infrastructure
to allocate as much memory as we want without problems.

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: May be stupid question ;-)

[Petko Manolov]

Rik van Riel wrote:
> 
> Currently not, unless you compile in all sorts of useless
> drivers (or you have a machine with 30+ different kinds of
> extension cards)...

;-) No, i'm currently trying to make the kernel as small as possible
to fit in 2M of RAM (for embeded system) without any driver.

> Most of the runtime tables are allocated after the memory
> stuff has been taken care off. Then we have the infrastructure
> to allocate as much memory as we want without problems.

Yes, but all page tables are for user level code/data. I mean
we're in trouble when not all of the kernel code is paged.

-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

4M kernel pages

[Petko Manolov]

I red in the intel docs that it is possile to have mixed
4K and 4M pages for pentium+ machines. Also we have less
TLB misses when the kernel is in 4M page. I know Linus 
don't like the idea of mixing different page sizes but
if this a improvemet...

-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[Petko Manolov]

David Mentr\'e wrote:
> 
> Petko Manolov <petkan@varel.bg> writes:
> 
> > Also we have less TLB misses when the kernel is in 4M page.
> 
> The kernel is already using 4M pages (for a long time now).

Yes, i know that. I took a look at 
linux/arch/i386/mm/init.c - paging_init().
Yes we rise PSE bit in cr4 but don't rise the PS bit in
the pade directory entry for the kernel - which means the
kernel is in 4K pages.

regards
-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[David Mentr\'e]

Petko Manolov <petkan@varel.bg> writes:

> Yes, i know that. I took a look at 
> linux/arch/i386/mm/init.c - paging_init().
> Yes we rise PSE bit in cr4 but don't rise the PS bit in
> the pade directory entry for the kernel - which means the
> kernel is in 4K pages.

Not exactly. 4MB pages for kernel are setted up _before_ the kernel is
started.
Look at arch/i386/kernel/head.S:


(around line 55 -- for the first CPU I suppose):

/*
 *      New page tables may be in 4Mbyte page mode and may
 *      be using the global pages. 
 *
 *      NOTE! We have to correct for the fact that we're
 *      not yet offset PAGE_OFFSET..
 */
#define cr4_bits mmu_cr4_features-__PAGE_OFFSET
        movl %cr4,%eax          # Turn on 4Mb pages
        orl cr4_bits,%eax
        movl %eax,%cr4
#endif



(around line 214 -- for other SMP CPUs I suppose):

        movb ready,%al          # First CPU if 0
        orb %al,%al
        jz 4f                   # First CPU skip this stuff
----->  movl %cr4,%eax          # Turn on 4Mb pages <------
        orl $16,%eax
        movl %eax,%cr4
        movl %cr3,%eax          # Intel specification clarification says
        movl %eax,%cr3          # to do this. Maybe it makes a difference.
                                # Who knows ?

To be honest, I'm not sure that this is done here, but I'm *sure* that
kernel uses 4Mb pages.

Best regards,
d.
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[Petko Manolov]

David Mentr\'e wrote:
> 
> Not exactly. 4MB pages for kernel are setted up _before_ the kernel is
> started.
> Look at arch/i386/kernel/head.S:

This is only for SMP machines.

> To be honest, I'm not sure that this is done here, but I'm *sure* that
> kernel uses 4Mb pages.

;-) I got sure by other way. In kernel mode i red the whole page
directory. All kernel page dir entries ended with LSB == 0xe3.
7th bit on means 4M pages. 1 and 0 bits means respectively r/w and
present.
The point is that 6th bit is also 1 when it supposed to be 0
acording to Intel docs.


Excuse me all for this boring mails!


regards
-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[David Mentr\'e]

Petko Manolov <petkan@varel.bg> writes:

> David Mentr\'e wrote:
> > 
> > Look at arch/i386/kernel/head.S:
> 
> This is only for SMP machines.

You are right. Shame on me (the #define is so BIG :).

> ;-) I got sure by other way.

To much brute force. :)

> In kernel mode i red the whole page directory. All kernel page dir
> entries ended with LSB == 0xe3.  7th bit on means 4M pages. 1 and 0
> bits means respectively r/w and present.

So, know we are sure this bit is set. But when (in the source) ?


[ in your first mail ]
> I took a look at linux/arch/i386/mm/init.c - paging_init().  Yes we
> rise PSE bit in cr4 but don't rise the PS bit in the pade directory
> entry for the kernel - which means the kernel is in 4K pages.

BTW, I think I've found when the PS bit is set. In fact, I you may have
overlooked arch/i386/mm/init.c. Around line 325, you have :

		/*
		 * If we're running on a Pentium CPU, we can use the 4MB
		 * page tables. 
		 *
		 * The page tables we create span up to the next 4MB
		 * virtual memory boundary, but that's OK as we won't
		 * use that memory anyway.
		 */
		if (boot_cpu_data.x86_capability & X86_FEATURE_PSE) {
			unsigned long __pe;

			set_in_cr4(X86_CR4_PSE);
			boot_cpu_data.wp_works_ok = 1;
			__pe = _KERNPG_TABLE + _PAGE_4M + __pa(address); <----
			/* Make it "global" too if supported */
			if (boot_cpu_data.x86_capability & X86_FEATURE_PGE) {
				set_in_cr4(X86_CR4_PGE);
				__pe += _PAGE_GLOBAL;
			}
			pgd_val(*pg_dir) = __pe;
			pg_dir++;
			address += 4*1024*1024;
			continue;
		}

At the line marked '<---', the macro _PAGE_4M set the PS bit (macro
defined in include/asm-i386/pgtable.h).  The code then setup the page
directory with __pe ('pgd_val(*pg_dir) = __pe;').

Is it right ? Or you where looking at another page directory ? (I'm far
from an expert in both kernel and i386 asm)

> The point is that 6th bit is also 1 when it supposed to be 0
> acording to Intel docs.

Yes. But, as it is reserved, it may be a hiden feature of intel procs. ;)

> Excuse me all for this boring mails!

No. It's interesting to know how things are done. And while trying to
explain this, I'm learning the Linux kernel. :)

Best regards,
d.
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[Petko Manolov]

David Mentr\'e wrote:
> 
> To much brute force. :)

Nope, i have already my own 2-3 drivers as modules. So the only thing
i had to do was:
	__asm__ __volatile__ (
	"movl	%%cr3, %0\n\t"
	:"=q" (__cr3));
	for( i=0; i<1024; i++ )
		printk("0x%x, ", (int)*(__cr3+i) );

in the init_module(). 

> BTW, I think I've found when the PS bit is set. In fact, I you may have
> overlooked arch/i386/mm/init.c. Around line 325, you have :
... 
>             __pe = _KERNPG_TABLE + _PAGE_4M + __pa(address); <----
... 
> Is it right ? Or you where looking at another page directory ? (I'm far
> from an expert in both kernel and i386 asm)

Yes, you catch it. I realy overlooked in my first glance while
i was looking for other thing.
 
> No. It's interesting to know how things are done. And while trying to
> explain this, I'm learning the Linux kernel. :)

;-) Me too. I'll keep on looking at mm.
As Linus said it can be a bitch ;-))

regards
-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[Rik van Riel]

On Mon, 16 Nov 1998, Petko Manolov wrote:

> I red in the intel docs that it is possile to have mixed
> 4K and 4M pages for pentium+ machines. Also we have less
> TLB misses when the kernel is in 4M page. I know Linus 
> don't like the idea of mixing different page sizes but
> if this a improvemet...

Been there, done that. Linux has had this implemented for
ages, in fact it's such a long time ago that I don't
remember when it was :)

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org

Re: 4M kernel pages

[Petko Manolov]

Rik van Riel wrote:
> 
> Been there, done that. Linux has had this implemented for
> ages, in fact it's such a long time ago that I don't
> remember when it was :)

Thanks.
David and i refound it by the harder way ;-)

regards
-- 
Petko Manolov - petkan@varel.bg
http://www.varel.bg/~petkan
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org