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 thou
PCB
> > to catch overruns.
>
> Maybe I'm just 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 ?
>
> Regar
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-hackers" in the body of the message
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 t
> 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
> swi_net
CTED]>
> >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:
>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:
>
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
un
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 rea
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
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 runnin
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
swi_net_next
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
> e
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
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
> 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.
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 tell
--- 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 t
--- 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
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_inpu
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 so
:
:
: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 diffe
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 available.
>
> --- 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
--- 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 interrupt
(
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 variable
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,
:
: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.
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
: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() re
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() respectivel
31 matches
Mail list logo
