kernel stack size so small ? I understand there should be no
need in huge stack, but why so damn small ? Would someone explain please ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
dumb, but I still don't understand, what is the reason of
keeping kernel stack size so small ? I understand there should be no
need in huge stack, but why so damn small ? Would someone explain please ?
Regards,
Eugene
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd
In message [EMAIL PROTECTED] Julian
Elischer writes:
: We may go to 2 pages but really 1 page is enough as long as people
: don't store structures on the stack. It's been kept small to keep the
: overhead of processes and threads down. When we get threads (KSE) we may
: have theoretically
Weiguang SHI wrote:
A closer look at the code /usr/src/sys/i386/i386/locore.s astonished
me with the fact that the kernel stack size for a process, at least
for process 0, is 2*4096-sizeof(struct user) = 3988 bytes, less than
even one page.
Anyone to verify this, please?
BTW, I am
I'm developing some code running in kernel that use a lot of stack. And it
seems i run into stack overflow. This results in some proc structure
related parts overwrite (particulary p-p_stats-p_timer[ITIMER_PROF]) and
unexpected signals. (Otherwise, it usually page faults inside
Hi!
I'm developing some code running in kernel that use a lot of stack. And it
seems i run into stack overflow. This results in some proc structure
related parts overwrite (particulary p-p_stats-p_timer[ITIMER_PROF]) and
unexpected signals. (Otherwise, it usually page faults inside
the kernel stack is a VERY LIMITED resource
basically you have about 4 or 5 Kbytes per process.
if you overflow it you write over your signal information..
you should MALLOC space and use a pointer to it..
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
Hi!
I'm developing some code running
Hi! Thanks for light speed response!
On Tue, 7 Aug 2001, Julian Elischer wrote:
the kernel stack is a VERY LIMITED resource
basically you have about 4 or 5 Kbytes per process.
Oops... And there is no hope to enlarge it?
if you overflow it you write over your signal information..
That's
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
Hi! Thanks for light speed response!
On Tue, 7 Aug 2001, Julian Elischer wrote:
the kernel stack is a VERY LIMITED resource
basically you have about 4 or 5 Kbytes per process.
Oops... And there is no hope to enlarge it?
none really.
Julian Elischer wrote:
the kernel stack is a VERY LIMITED resource
basically you have about 4 or 5 Kbytes per process.
if you overflow it you write over your signal information..
you should MALLOC space and use a pointer to it..
Would adding an unmapped or read-only guard page be
From: Julian Elischer [EMAIL PROTECTED]
To: Semen A. Ustimenko [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Kernel stack size
Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT)
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
Hi! Thanks for light speed response!
On Tue, 7 Aug 2001
PROTECTED]
CC: [EMAIL PROTECTED]
Subject: Re: Kernel stack size
Date: Tue, 7 Aug 2001 13:29:25 -0700 (PDT)
On Wed, 8 Aug 2001, Semen A. Ustimenko wrote:
Hi! Thanks for light speed response!
On Tue, 7 Aug 2001, Julian Elischer wrote:
the kernel stack is a VERY LIMITED resource
A closer look at the code /usr/src/sys/i386/i386/locore.s astonished
me with the fact that the kernel stack size for a process, at least
for process 0, is 2*4096-sizeof(struct user) = 3988 bytes, less than
even one page.
Anyone to verify this, please?
BTW, I am looking at the 4.3-stable code
fault land in a
hurry.
On Fri, 27 Jul 2001, Weiguang SHI wrote:
A closer look at the code /usr/src/sys/i386/i386/locore.s astonished
me with the fact that the kernel stack size for a process, at least
for process 0, is 2*4096-sizeof(struct user) = 3988 bytes, less than
even one page.
Anyone
On Thu, 30 Nov 2000, Mike Smith wrote:
The routines have a nesting of 10-12 functions having 10-100 lines each.
Could you tell us what is the minimum available run time memory in the
per-process kernel stack for running these routines?
You can generally assume that you have about 4k of
Hi
We have implemented a device driver on FreeBSD 4.0 and x86 architecture.
The device driver has routines for servicing I/O requests. I understand
that these routines run in the top part of the kernel stack.
The routines have a nesting of 10-12 functions having 10-100 lines each.
Could you
Hi
We have implemented a device driver on FreeBSD 4.0 and x86 architecture.
The device driver has routines for servicing I/O requests. I understand
that these routines run in the top part of the kernel stack.
The routines have a nesting of 10-12 functions having 10-100 lines each.
Could
:
:Hi
:
:Thanks for your reply. I have two other questions
:regarding this matter.
:
:Would it be possible to extend the kernel stack?
:The reason is that some of the crypto and hashing
:algorithms use relatively large contexts which for
:performance reasons are currently allocated on the
Would it be possible to pre-allocate a block of memory
and then "switch" stacks in my interrupt routine? This
may be far off, but my only other option is going
through ~1 lines of code and examining all places
where local variables are declared. If I could somehow
do this in a different way,
In message [EMAIL PROTECTED] Jacques Fourie writes:
: Would it be possible to pre-allocate a block of memory
: and then "switch" stacks in my interrupt routine? This
: may be far off, but my only other option is going
: through ~1 lines of code and examining all places
: where local variables
--- Warner Losh [EMAIL PROTECTED] wrote:
10k lines in an interrupt routine sounds to be way
more work than you
want to do in an interrupt routine. Maybe you could
use a work queue
and deal with it that way. There isn't much I can
The ~10k lines of code is in a software
First of all, I would like to say a big thanks for all
of the replies I got so far. I really appreciate it.
Here is a more detailed description of what the code
does. It is for a commercial IPsec product. I know
that IPsec is available in FreeBSD, but this started
long before KAME was
:
:
:Would it be possible to pre-allocate a block of memory
:and then "switch" stacks in my interrupt routine? This
:may be far off, but my only other option is going
:through ~1 lines of code and examining all places
:where local variables are declared. If I could somehow
:do this in a
Jacques Fourie wrote:
Would it be possible to pre-allocate a block of memory
and then "switch" stacks in my interrupt routine? This
may be far off, but my only other option is going
through ~1 lines of code and examining all places
where local variables are declared. If I could somehow
Jacques Fourie wrote:
Hi
Please excuse any silly questions, but I am stuck with
a problem that I can't find the answer for.
I wrote a KLD module that performs encryption on
network packets in the kernel. Packets are intercepted
for encryption on a ethernet level (in ether_input()
and
--- Julian Elischer [EMAIL PROTECTED] wrote:
Why are you not using the netgraph system, which was
specifically
designed
for this? it allows you to divert eherne packets
When we started on this, (~2years ago) I was not aware
of the netgraph functionality. I agree that it would
be better to
--- Matt Dillon [EMAIL PROTECTED] wrote:
You can theoretically increase UPAGES in
/usr/src/sys/i386/include/param.h
I increased UPAGES from 2 to 8 and everything seems to
be working as it should. The device in question will
very much be a dedicated IPsec device and will not be
running that
Hi
Please excuse any silly questions, but I am stuck with
a problem that I can't find the answer for.
I wrote a KLD module that performs encryption on
network packets in the kernel. Packets are intercepted
for encryption on a ethernet level (in ether_input()
and ether_output_frame()
:Hi
:
:Please excuse any silly questions, but I am stuck with
:a problem that I can't find the answer for.
:
:I wrote a KLD module that performs encryption on
:network packets in the kernel. Packets are intercepted
:for encryption on a ethernet level (in ether_input()
:and ether_output_frame()
Hi
Thanks for your reply. I have two other questions
regarding this matter.
Would it be possible to extend the kernel stack?
The reason is that some of the crypto and hashing
algorithms use relatively large contexts which for
performance reasons are currently allocated on the
stack.
If this is
30 matches
Mail list logo
