Re: is there a limit on bss size?
On Fri, 6 Oct 2000, Philipp Rumpf wrote: > On Fri, Oct 06, 2000 at 12:32:35PM +0300, Petko Manolov wrote: > > It is not so difficult as it looks. > > I don't see it being difficult at all ... > > > The master pgd looking as: > > > > .org 0x1000 > > ENTRY(swapper_pg_dir) > > .long 0x00102007 > > .long 0x00103007 > > .fill BOOT_USER_PGD_PTRS-2,4,0 > > /* default: 766 entries */ > > .long 0x00102007 > > .long 0x00103007 > > /* default: 254 entries */ > > .fill BOOT_KERNEL_PGD_PTRS-2,4,0 > > > > > > should become: > > > > > > .org 0x1000 > > ENTRY(swapper_pg_dir) > > .long 0x00102007 > > .long 0x00103007 > > # every entry addresses 4 MB exactly > > # so add as much as you want > > .long 0x0010X007 > > .fill BOOT_USER_PGD_PTRS-X+2,4,0 > > I'm unconvinced we need to map more than 4 MB into low virtual addresses; > nothing seems to break with > > ENTRY(swapper_pg_dir) > .long 0x00102007 > .fill BOOT_USER_PGD_PTRS-1,4,0 > Hi Phillip, Ah, _now_ I understand what you are talking about (took me only slightly over a month ;) and so can answer -- try making a huge bzImage (a few megs) and boot with it. That was the main reason Werner added the extra stuff somewhere around 2.3.99-preX. Having said that, I still don't see why we actually need a specific label (like pg1) for each successive page worth of pte's if we are filling them with data starting from pg0 until we hit empty_zero_page (as I asked in my other message). Regards, Tigran PS. I cc'd the guy who was looking to extend the page tables for booting with huge bss also... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Fri, 6 Oct 2000, Philipp Rumpf wrote: On Fri, Oct 06, 2000 at 12:32:35PM +0300, Petko Manolov wrote: It is not so difficult as it looks. I don't see it being difficult at all ... The master pgd looking as: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 .fill BOOT_USER_PGD_PTRS-2,4,0 /* default: 766 entries */ .long 0x00102007 .long 0x00103007 /* default: 254 entries */ .fill BOOT_KERNEL_PGD_PTRS-2,4,0 should become: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 # every entry addresses 4 MB exactly # so add as much as you want .long 0x0010X007 .fill BOOT_USER_PGD_PTRS-X+2,4,0 I'm unconvinced we need to map more than 4 MB into low virtual addresses; nothing seems to break with ENTRY(swapper_pg_dir) .long 0x00102007 .fill BOOT_USER_PGD_PTRS-1,4,0 Hi Phillip, Ah, _now_ I understand what you are talking about (took me only slightly over a month ;) and so can answer -- try making a huge bzImage (a few megs) and boot with it. That was the main reason Werner added the extra stuff somewhere around 2.3.99-preX. Having said that, I still don't see why we actually need a specific label (like pg1) for each successive page worth of pte's if we are filling them with data starting from pg0 until we hit empty_zero_page (as I asked in my other message). Regards, Tigran PS. I cc'd the guy who was looking to extend the page tables for booting with huge bss also... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Fri, Oct 06, 2000 at 12:32:35PM +0300, Petko Manolov wrote: > It is not so difficult as it looks. I don't see it being difficult at all ... > The master pgd looking as: > > .org 0x1000 > ENTRY(swapper_pg_dir) > .long 0x00102007 > .long 0x00103007 > .fill BOOT_USER_PGD_PTRS-2,4,0 > /* default: 766 entries */ > .long 0x00102007 > .long 0x00103007 > /* default: 254 entries */ > .fill BOOT_KERNEL_PGD_PTRS-2,4,0 > > > should become: > > > .org 0x1000 > ENTRY(swapper_pg_dir) > .long 0x00102007 > .long 0x00103007 > # every entry addresses 4 MB exactly > # so add as much as you want > .long 0x0010X007 > .fill BOOT_USER_PGD_PTRS-X+2,4,0 I'm unconvinced we need to map more than 4 MB into low virtual addresses; nothing seems to break with ENTRY(swapper_pg_dir) .long 0x00102007 .fill BOOT_USER_PGD_PTRS-1,4,0 here and I don't see anything that would break unless we moved head.S ... > But i honestly don't see the point of all that. Arbitrary kernel size limits are bad. Not complaining about a kernel that definitely won't boot while building is even worse, and I think the latter is actually pretty easy to fix ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
It is not so difficult as it looks. The master pgd looking as: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 .fill BOOT_USER_PGD_PTRS-2,4,0 /* default: 766 entries */ .long 0x00102007 .long 0x00103007 /* default: 254 entries */ .fill BOOT_KERNEL_PGD_PTRS-2,4,0 should become: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 # every entry addresses 4 MB exactly # so add as much as you want .long 0x0010X007 .fill BOOT_USER_PGD_PTRS-X+2,4,0 /* default: 766-X entries */ .long 0x00102007 .long 0x00103007 # every entry addresses 4 MB exactly # so add as much as you want /* default: 254-X entries */ .fill BOOT_KERNEL_PGD_PTRS-X+2,4,0 empty_zero_page, empty_bad_page, etc... offsets should be also appropriately changed and the corresponding code in mm init as well. But i honestly don't see the point of all that. best, Petkan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Fri, 6 Oct 2000, Petko Manolov wrote:
> Philipp Rumpf wrote:
> >
> > On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> > > Hi,
> > >
> > > I put a simple construct in kernel/sched.c like this:
> > >
> > > struct runq_log_s {
> > > char comm[16];
> > > int pid;
> > > } runq_log[1024*1024];
> > >
> > > and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
>
>
> Is it impossible to allocate this array dynamically? I am not sure if we
> have
> to change too many things in startup code. If yes, we must have good
> enough
> arguments for Linus.
>
Nobody is suggesting to make any arguments for Linus. That code was just a
trivial "runq history log" thing I needed for finding out why the load on
my machine is always (at least) 1.0 and yet there is no apparent process
to be blamed for it.
What Philipp says is an interesting excercise and I might try it
today. (for my present purposes reducing the size of the log was
sufficient).
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
Philipp Rumpf wrote:
>
> On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> > Hi,
> >
> > I put a simple construct in kernel/sched.c like this:
> >
> > struct runq_log_s {
> > char comm[16];
> > int pid;
> > } runq_log[1024*1024];
> >
> > and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Is it impossible to allocate this array dynamically? I am not sure if we
have
to change too many things in startup code. If yes, we must have good
enough
arguments for Linus.
> Look at the code in arch/i386/kernel/entry.S that initializes our temporary
> page tables:
Actually this code is from arch/i386/kernel/head.S ;-)
> /*
> * Initialize page tables
> */
> movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
> movl $007,%eax /* "007" doesn't mean with right to kill, but
>PRESENT+RW+USER */
> 2: stosl
> add $0x1000,%eax
> cmp $empty_zero_page-__PAGE_OFFSET,%edi
> jne 2b
Actually when/where exactly mm init takes place should be checked first.
best,
Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
Philipp Rumpf wrote:
On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
Hi,
I put a simple construct in kernel/sched.c like this:
struct runq_log_s {
char comm[16];
int pid;
} runq_log[1024*1024];
and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Is it impossible to allocate this array dynamically? I am not sure if we
have
to change too many things in startup code. If yes, we must have good
enough
arguments for Linus.
Look at the code in arch/i386/kernel/entry.S that initializes our temporary
page tables:
Actually this code is from arch/i386/kernel/head.S ;-)
/*
* Initialize page tables
*/
movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
movl $007,%eax /* "007" doesn't mean with right to kill, but
PRESENT+RW+USER */
2: stosl
add $0x1000,%eax
cmp $empty_zero_page-__PAGE_OFFSET,%edi
jne 2b
Actually when/where exactly mm init takes place should be checked first.
best,
Petkan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Fri, 6 Oct 2000, Petko Manolov wrote:
Philipp Rumpf wrote:
On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
Hi,
I put a simple construct in kernel/sched.c like this:
struct runq_log_s {
char comm[16];
int pid;
} runq_log[1024*1024];
and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Is it impossible to allocate this array dynamically? I am not sure if we
have
to change too many things in startup code. If yes, we must have good
enough
arguments for Linus.
Nobody is suggesting to make any arguments for Linus. That code was just a
trivial "runq history log" thing I needed for finding out why the load on
my machine is always (at least) 1.0 and yet there is no apparent process
to be blamed for it.
What Philipp says is an interesting excercise and I might try it
today. (for my present purposes reducing the size of the log was
sufficient).
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
It is not so difficult as it looks. The master pgd looking as: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 .fill BOOT_USER_PGD_PTRS-2,4,0 /* default: 766 entries */ .long 0x00102007 .long 0x00103007 /* default: 254 entries */ .fill BOOT_KERNEL_PGD_PTRS-2,4,0 should become: .org 0x1000 ENTRY(swapper_pg_dir) .long 0x00102007 .long 0x00103007 # every entry addresses 4 MB exactly # so add as much as you want .long 0x0010X007 .fill BOOT_USER_PGD_PTRS-X+2,4,0 /* default: 766-X entries */ .long 0x00102007 .long 0x00103007 # every entry addresses 4 MB exactly # so add as much as you want /* default: 254-X entries */ .fill BOOT_KERNEL_PGD_PTRS-X+2,4,0 empty_zero_page, empty_bad_page, etc... offsets should be also appropriately changed and the corresponding code in mm init as well. But i honestly don't see the point of all that. best, Petkan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
> Hi,
>
> I put a simple construct in kernel/sched.c like this:
>
> struct runq_log_s {
> char comm[16];
> int pid;
> } runq_log[1024*1024];
>
> and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Look at the code in arch/i386/kernel/entry.S that initializes our temporary
page tables:
/*
* Initialize page tables
*/
movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
movl $007,%eax /* "007" doesn't mean with right to kill, but
PRESENT+RW+USER */
2: stosl
add $0x1000,%eax
cmp $empty_zero_page-__PAGE_OFFSET,%edi
jne 2b
/*
* The page tables are initialized to only 8MB here - the final page
* tables are set up later depending on memory size.
*/
.org 0x2000
ENTRY(pg0)
.org 0x3000
ENTRY(pg1)
My guess is we're trying to access higher addresses, and getting another
fault for those. Could you try modifying head.S in the obvious way to
map more than 8MB during the boot process ?
> I will try with a smaller value and see what is the limit but am curious
> as to the reason. The last thing I see is Uncompressing linux... Maybe the
> code in arch/i386/kernel/head.S which clears BSS is broken at "large
> values"?
That code would indeed be what causes the page faults we cannot handle,
if my theory is correct.
Philipp Rumpf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: is there a limit on bss size?
On Thu, Oct 05, 2000 at 04:30:35PM +0100, Tigran Aivazian wrote:
Hi,
I put a simple construct in kernel/sched.c like this:
struct runq_log_s {
char comm[16];
int pid;
} runq_log[1024*1024];
and the kernel didn't boot. Yes, I understand it is 20M of bss - so what?
Look at the code in arch/i386/kernel/entry.S that initializes our temporary
page tables:
/*
* Initialize page tables
*/
movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
movl $007,%eax /* "007" doesn't mean with right to kill, but
PRESENT+RW+USER */
2: stosl
add $0x1000,%eax
cmp $empty_zero_page-__PAGE_OFFSET,%edi
jne 2b
/*
* The page tables are initialized to only 8MB here - the final page
* tables are set up later depending on memory size.
*/
.org 0x2000
ENTRY(pg0)
.org 0x3000
ENTRY(pg1)
My guess is we're trying to access higher addresses, and getting another
fault for those. Could you try modifying head.S in the obvious way to
map more than 8MB during the boot process ?
I will try with a smaller value and see what is the limit but am curious
as to the reason. The last thing I see is Uncompressing linux... Maybe the
code in arch/i386/kernel/head.S which clears BSS is broken at "large
values"?
That code would indeed be what causes the page faults we cannot handle,
if my theory is correct.
Philipp Rumpf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
