From: junkio@cox.net
To: =?iso-2022-jp-2?b?ShsuQRtOdnJuRW5nZWw=?= <joern@wohnheim.fh-wedel.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Port SquashFS to 2.6
Date: Mon, 21 Jul 2003 19:52:39 -0700 [thread overview]
Message-ID: <7vd6g3uvbc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <fa.hre90bn.e6k5pf@ifi.uio.no> (joern@wohnheim.fh-wedel.de's message of "Sun, 20 Jul 2003 08:25:16 GMT")
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 1243 bytes --]
>>>>> "JE" == J^[.A^[NvrnEngel <joern@wohnheim.fh-wedel.de> writes:
JE> On Sat, 19 July 2003 22:40:22 -0700, junkio@cox.net wrote:
>> - I would imagine that the acceptable stack usage for functions
>> would depend on where they are called and what they call.
>> Coulc you suggest a rule-of-thumb number for
>> address_space_operations.readpage (say, would 1kB be OK but
>> not 3kB?)
JE> Depending on where and what you do,...
Well, isn't asking about address_space_operations.readpage
specific enough?
JE> ... also depends a bit on the architecture. s390 has
JE> giant stacks because function call overhead is huge, ...
The discussion was about putting variables (or arrays or large
structs) the kernel programmer defines on the stack, and I do
not think architecture calling convention has much to do with
this.
If an architecture has a big stack usage per call that is
imposed by the ABI, and larger kernel stack is allocated
compared to other architectures because of this reason,
shouldn't there be about the same amount of usable space left
for the kernel programs within the allocated per-process kernel
stack space to use? If that is not the case then the port to
that particular architecture would not be optimal, wouldn't it?
next parent reply other threads:[~2003-07-22 2:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.k0do8p6.ch6pps@ifi.uio.no>
[not found] ` <fa.hre90bn.e6k5pf@ifi.uio.no>
2003-07-22 2:52 ` junkio [this message]
2003-07-22 3:42 ` [PATCH] Port SquashFS to 2.6 Valdis.Kletnieks
2003-07-22 10:20 ` Jörn Engel
2003-07-22 10:16 ` Jörn Engel
2003-07-22 10:36 John Bradford
2003-07-22 10:47 ` Jörn Engel
-- strict thread matches above, loose matches on Subject: below --
2003-07-19 22:59 junkio
2003-07-19 23:35 ` David Dillow
2003-07-20 5:40 ` junkio
2003-07-20 8:22 ` Jörn Engel
2003-07-20 10:16 ` postmaster
2003-07-20 10:38 ` Jörn Engel
2003-07-20 1:50 ` Bernd Eckenfels
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vd6g3uvbc.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=joern@wohnheim.fh-wedel.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).