[STACK] >3k call path in reiserfs

[STACK] >3k call path in reiserfs

[Jörn Engel]

reiserfs has some stack-hungry functions as well.  Could you put them
on a diet?

stackframes for call path too long (3024):
    size  function
      32  reiserfs_delete_inode
       0  reiserfs_delete_object
     132  reiserfs_do_truncate
     468  reiserfs_cut_from_item
     492  reiserfs_delete_item
     104  search_for_position_by_key
      16  search_by_entry_key
     208  search_by_key
       0  __bread
       0  __getblk
       0  __getblk_slow
       0  find_or_create_page
       0  add_to_page_cache_lru
       0  lru_cache_add
       0  preempt_schedule
      84  schedule
      16  __put_task_struct
      20  audit_free
      36  audit_log_start
      16  __kmalloc
       0  __get_free_pages
      28  __alloc_pages
     284  try_to_free_pages
       0  out_of_memory
       0  mmput
      16  exit_aio
       0  __put_ioctx
      16  do_munmap
       0  split_vma
      36  vma_adjust
       0  fput
       0  __fput
       0  locks_remove_flock
      12  panic
       0  sys_sync
       0  sync_inodes
     308  sync_inodes_sb
       0  do_writepages
     128  mpage_writepages
       4  write_boundary_block
       0  ll_rw_block
      28  submit_bh
       0  bio_alloc
      88  mempool_alloc
     256  wakeup_bdflush
      20  pdflush_operation
       0  printk
      16  release_console_sem
      16  __wake_up
       0  printk
       0  vscnprintf
      32  vsnprintf
     112  number

Jörn

-- 
A quarrel is quickly settled when deserted by one party; there is
no battle unless there be two.
-- Seneca

Re: [STACK] >3k call path in reiserfs

[Chris Mason]

On Wed, 2004-06-09 at 08:22, Jörn Engel wrote:
> reiserfs has some stack-hungry functions as well.  Could you put them
> on a diet?
> 
Yes, we should be able to fix things by getting rid of some of the
inlines in a few spots (some funcs are much too large for inlining). 
I'll send a patch out this morning.

-chris

Re: [STACK] >3k call path in reiserfs

[Chris Mason]

On Wed, 2004-06-09 at 08:31, Chris Mason wrote:
> On Wed, 2004-06-09 at 08:22, Jörn Engel wrote:
> > reiserfs has some stack-hungry functions as well.  Could you put them
> > on a diet?
> > 
> Yes, we should be able to fix things by getting rid of some of the
> inlines in a few spots (some funcs are much too large for inlining). 
> I'll send a patch out this morning.

No such luck, the real offender is having tree balance structs on the
stack.  We need to switch to kmalloc for those, which will be mean some
extra work to make sure we don't schedule at the wrong time.

In other words, not the trivial patch I was hoping for, but I'm cooking
one up.

-chris

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Chris Mason wrote:

>On Wed, 2004-06-09 at 08:31, Chris Mason wrote:
>  
>
>>On Wed, 2004-06-09 at 08:22, Jörn Engel wrote:
>>    
>>
>>>reiserfs has some stack-hungry functions as well.  Could you put them
>>>on a diet?
>>>
>>>      
>>>
>>Yes, we should be able to fix things by getting rid of some of the
>>inlines in a few spots (some funcs are much too large for inlining). 
>>I'll send a patch out this morning.
>>    
>>
>
>No such luck, the real offender is having tree balance structs on the
>stack.  We need to switch to kmalloc for those, which will be mean some
>extra work to make sure we don't schedule at the wrong time.
>
>In other words, not the trivial patch I was hoping for, but I'm cooking
>one up.
>
>-chris
>
>
>
>
>  
>
Can you give me some background on whether this is causing real problems 
for real users?

Re: [STACK] >3k call path in reiserfs

[Chris Mason]

On Wed, 2004-06-09 at 13:06, Hans Reiser wrote:

> >No such luck, the real offender is having tree balance structs on the
> >stack.  We need to switch to kmalloc for those, which will be mean some
> >extra work to make sure we don't schedule at the wrong time.
> >
> >In other words, not the trivial patch I was hoping for, but I'm cooking
> >one up.

> >
> Can you give me some background on whether this is causing real problems 
> for real users?

Especially with the 4k stack option enabled, it will cause real problems
for real users.  A better change would be to cut down on the size of the
tree balance struct, but that would be more invasive.  For starters we
might be able to switch from ints to shorts for some of the arrays.

-chris

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Chris Mason wrote:

>On Wed, 2004-06-09 at 13:06, Hans Reiser wrote:
>
>  
>
>>>No such luck, the real offender is having tree balance structs on the
>>>stack.  We need to switch to kmalloc for those, which will be mean some
>>>extra work to make sure we don't schedule at the wrong time.
>>>
>>>In other words, not the trivial patch I was hoping for, but I'm cooking
>>>one up.
>>>      
>>>
>
>  
>
>>Can you give me some background on whether this is causing real problems 
>>for real users?
>>    
>>
>
>Especially with the 4k stack option enabled, it will cause real problems
>for real users.  A better change would be to cut down on the size of the
>tree balance struct, but that would be more invasive.  For starters we
>might be able to switch from ints to shorts for some of the arrays.
>
>-chris
>
>
>
>
>  
>
Can you tell me about the "4k stack option"?

Re: [STACK] >3k call path in reiserfs

[Dave Jones]

On Wed, Jun 09, 2004 at 11:04:49AM -0700, Hans Reiser wrote:
 > >>Can you give me some background on whether this is causing real problems 
 > >>for real users?
 > >
 > >Especially with the 4k stack option enabled, it will cause real problems
 > >for real users.  A better change would be to cut down on the size of the
 > >tree balance struct, but that would be more invasive.  For starters we
 > >might be able to switch from ints to shorts for some of the arrays.
 > >
 > >-chris
 > >
 > Can you tell me about the "4k stack option"?

Arjan's original patch & announcement are at
http://people.redhat.com/arjanv/4kstack.patch

		Dave

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Dave Jones wrote:

>On Wed, Jun 09, 2004 at 11:04:49AM -0700, Hans Reiser wrote:
> > >>Can you give me some background on whether this is causing real problems 
> > >>for real users?
> > >
> > >Especially with the 4k stack option enabled, it will cause real problems
> > >for real users.  A better change would be to cut down on the size of the
> > >tree balance struct, but that would be more invasive.  For starters we
> > >might be able to switch from ints to shorts for some of the arrays.
> > >
> > >-chris
> > >
> > Can you tell me about the "4k stack option"?
>
>Arjan's original patch & announcement are at
>http://people.redhat.com/arjanv/4kstack.patch
>
>		Dave
>
>
>
>  
>
Forcing kernel developers to distort their coding to keep stack sizes 
small is not a good idea, as it makes the whole kernel harder to code 
for a not very compelling (for 99% of users, please argue with me if you 
think it is otherwise) benefit.

I do not think I favor disturbing V3's stability for the sake of the 4k 
stack option, but my mind is still open.

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Wed, 9 June 2004 16:40:18 -0700, Hans Reiser wrote:
> >
> Forcing kernel developers to distort their coding to keep stack sizes 
> small is not a good idea, as it makes the whole kernel harder to code 
> for a not very compelling (for 99% of users, please argue with me if you 
> think it is otherwise) benefit.
> 
> I do not think I favor disturbing V3's stability for the sake of the 4k 
> stack option, but my mind is still open.

Apart from the fact that v3 appears to be safe on this front, your
perspective of kernel development doesn't seem to match that of most
developers.

o The kernel proper has no stable interface, it changes all of the
time.  Breaking peripheral kernel code (i.e. filesystems and device
drivers) with any change is not considered a problem.  If someone
cares about the peripheral code, it will get fixed.

o Noone has special rights to any code in the kernel.  You've accepted
the GPL and thereby given anyone the right to make changes to reiser3
and to distribute the changed code.  Active maintainership is usually
valued, but without that, noone is special.

It appears to me that most developers agree to the two point above,
but you have some problems with them, at least lately.  Am i wrong?

Jörn

-- 
When you close your hand, you own nothing. When you open it up, you
own the whole world.
-- Li Mu Bai in Tiger & Dragon

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Jörn Engel wrote:

>
>
>It appears to me that most developers agree to the two point above,
>but you have some problems with them, at least lately.  Am i wrong?
>
>Jörn
>
>  
>
I have a concept of stable version and development version.  V3 is the 
stable release branch, and should not be disturbed except for bug 
fixes.  V4 is where all new features go. 
In not very long, V4 will enter code freeze, and we will open a V5 
branch where all new features will go.

Filesystem users want conservative release management.  This is not 
gimp, this is a filesystem.  It must be a zero defect product or it is 
useless.

This is all part of what responsible release management is about.   I 
was the junior whiz kid in professional release management teams before 
starting Namesys.  I listened to my elders and learned from them.  My 
standards for professional conduct in this arena are higher than yours 
as a result of that. 

You are a bunch of young kids who lack professional experience in 
release management.  That is ok, but don't get aggressive about it.

I have no desire to pay for your mistakes, and as the official 
maintainer it is my responsibility to ensure that neither I nor the 
users pay for the mistakes of those who add bugs to stable branches 
instead of adding them to the development branches where they belong.

Hans

Re: [STACK] >3k call path in reiserfs

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

On Fri, 2004-06-11 at 04:49, Hans Reiser wrote:
> >
> I have a concept of stable version and development version.  V3 is the 
> stable release branch, and should not be disturbed except for bug 
> fixes.  

Hans,

I would call stack use like this a bug fix. Let me explain why: in the
2.4 kernel you ALREADY have effectively a 4Kb stack (it's 8Kb but when
you subtract 1.6Kb for the task struct and about 2Kb for soft/hardirq
context about 4Kb is left). It's just more of a lottery there about
if/when you get hit by an irq or not, while with 4KSTACKS in 2.6 the
odds of the lottery changed. I'm sure that as maintainer of a filesystem
that, as you say, is critical and holds peoples email an other critical
data, you rather not play odds at all, regardless of what they are, and
want to play for certainty.

Greetings,
     Arjan van de Ven

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Thu, 10 June 2004 19:49:04 -0700, Hans Reiser wrote:
> Jörn Engel wrote:
> 
> >It appears to me that most developers agree to the two point above,
> >but you have some problems with them, at least lately.  Am i wrong?
> 
> This is all part of what responsible release management is about.   I 
> was the junior whiz kid in professional release management teams before 
> starting Namesys.  I listened to my elders and learned from them.  My 
> standards for professional conduct in this arena are higher than yours 
> as a result of that. 
> 
> You are a bunch of young kids who lack professional experience in 
> release management.  That is ok, but don't get aggressive about it.
> 
> I have no desire to pay for your mistakes, and as the official 
> maintainer it is my responsibility to ensure that neither I nor the 
> users pay for the mistakes of those who add bugs to stable branches 
> instead of adding them to the development branches where they belong.

Well, this ain't OpenBSD.  They have a strict 6month release schedule,
so your type of development works just fine for them.  Linux has
something like a very relaxed 24month+ release "schedule", which is
far too long for some people.  As a result, the Linux "stable" kernel
is a lot less stable than the OpenBSD one.

But long release cycles also have their advantages and - most
important - they work with Linus.  So effectively, we all have to
accept them and deal with the consequenses.  I really understand and
partially share your doubts, but what does it help? ;)

Jörn

-- 
You can't tell where a program is going to spend its time. Bottlenecks
occur in surprising places, so don't try to second guess and put in a
speed hack until you've proven that's where the bottleneck is.
-- Rob Pike

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Jörn Engel wrote:

>On Thu, 10 June 2004 19:49:04 -0700, Hans Reiser wrote:
>  
>
>>Jörn Engel wrote:
>>
>>    
>>
>>>It appears to me that most developers agree to the two point above,
>>>but you have some problems with them, at least lately.  Am i wrong?
>>>      
>>>
>>This is all part of what responsible release management is about.   I 
>>was the junior whiz kid in professional release management teams before 
>>starting Namesys.  I listened to my elders and learned from them.  My 
>>standards for professional conduct in this arena are higher than yours 
>>as a result of that. 
>>
>>You are a bunch of young kids who lack professional experience in 
>>release management.  That is ok, but don't get aggressive about it.
>>
>>I have no desire to pay for your mistakes, and as the official 
>>maintainer it is my responsibility to ensure that neither I nor the 
>>users pay for the mistakes of those who add bugs to stable branches 
>>instead of adding them to the development branches where they belong.
>>    
>>
>
>Well, this ain't OpenBSD.  They have a strict 6month release schedule,
>so your type of development works just fine for them.  Linux has
>something like a very relaxed 24month+ release "schedule", which is
>far too long for some people.  As a result, the Linux "stable" kernel
>is a lot less stable than the OpenBSD one.
>
>But long release cycles also have their advantages and - most
>important - they work with Linus.  So effectively, we all have to
>accept them and deal with the consequenses.  I really understand and
>partially share your doubts, but what does it help? ;)
>
>Jörn
>
>  
>
Reiser4 is going to obsolete V3 in a few weeks.  V3 will be retained for 
compatibility reasons only, as V4 blows it away in performance.

You are right though that OpenBSD does some things better.

Hans

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Fri, 11 June 2004 09:32:31 -0700, Hans Reiser wrote:
> >
> Reiser4 is going to obsolete V3 in a few weeks.  V3 will be retained for 
> compatibility reasons only, as V4 blows it away in performance.

About three years ago, I switched from reiserfs to ext3.  And still, I
have some old reiserfs partitions around that I use.  Either I'm quite
unusual or reiser3 will stay around for a while. :)

> You are right though that OpenBSD does some things better.

For sure.  And still, I use and develop for Linux.

Jörn

-- 
When people work hard for you for a pat on the back, you've got
to give them that pat.
-- Robert Heinlein

Re: [STACK] >3k call path in reiserfs

[Paul Wagland]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]


On Jun 11, 2004, at 18:50, Jörn Engel wrote:

> On Fri, 11 June 2004 09:32:31 -0700, Hans Reiser wrote:
>>>
>> Reiser4 is going to obsolete V3 in a few weeks.  V3 will be retained 
>> for
>> compatibility reasons only, as V4 blows it away in performance.
>
> About three years ago, I switched from reiserfs to ext3.  And still, I
> have some old reiserfs partitions around that I use.  Either I'm quite
> unusual or reiser3 will stay around for a while. :)

You are not unusual at all. I switched from 2.4 kernels to 2.6 several 
months ago, and yet I still have production boxes running 2.2 
kernels... Not that changing kernel code would affect me, since those 
boxes are also running 4 year old kernels... And no, I won't tell you 
their IP's ;-)

>> You are right though that OpenBSD does some things better.
>
> For sure.  And still, I use and develop for Linux.

It is also worth pointing out that "linux" (aka the kernel) is quite 
different from *BSD, especially with OpenBSD, it should be more 
properly compared to a distribution, and most distributions do run on a 
different release cycle than does Linus.

Cheers,
Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [STACK] >3k call path in reiserfs

[Chris Mason]

On Fri, 2004-06-11 at 12:32, Hans Reiser wrote:

> Reiser4 is going to obsolete V3 in a few weeks.  V3 will be retained for 
> compatibility reasons only, as V4 blows it away in performance.
> 

This would be the conservative release management you were talking about
before, right?  It's going to take a considerable amount of time for v4
to obsolete v3, because it will take a considerable amount of time for
v4 to become stable under the wide range of conditions that filesystems
get used.

Please don't misunderstand this as a statement against v4, I would love
to see it be 1000x as fast as every other FS.  I'm only asking for some
kind of realism in the expectations you give the users.

-chris

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Chris Mason wrote:

>On Fri, 2004-06-11 at 12:32, Hans Reiser wrote:
>
>  
>
>>Reiser4 is going to obsolete V3 in a few weeks.  V3 will be retained for 
>>compatibility reasons only, as V4 blows it away in performance.
>>
>>    
>>
>
>This would be the conservative release management you were talking about
>before, right?  It's going to take a considerable amount of time for v4
>to obsolete v3, because it will take a considerable amount of time for
>v4 to become stable under the wide range of conditions that filesystems
>get used.
>  
>
A better statement would be:

V3 will exist for those who don't want to use the latest fs on the 
block, and for those who started to use V3 and don't care enough about 
performance and features to engage in the work needed to change (99% of 
existing users, unless someone funds convertfs).

>Please don't misunderstand this as a statement against v4, I would love
>to see it be 1000x as fast as every other FS.  I'm only asking for some
>kind of realism in the expectations you give the users.
>
>-chris
>
>
>
>
>  
>

Re: [STACK] >3k call path in reiserfs

[Timothy Miller]

Hans Reiser wrote:


> This is all part of what responsible release management is about.   I 
> was the junior whiz kid in professional release management teams before 
> starting Namesys.  I listened to my elders and learned from them.  My 
> standards for professional conduct in this arena are higher than yours 
> as a result of that.
> You are a bunch of young kids who lack professional experience in 
> release management.  That is ok, but don't get aggressive about it.
> 
> I have no desire to pay for your mistakes, and as the official 
> maintainer it is my responsibility to ensure that neither I nor the 
> users pay for the mistakes of those who add bugs to stable branches 
> instead of adding them to the development branches where they belong.


Don't get condescending.  Immature people don't like to be told that 
they are immature.  :)

Anyhow, I agree with you.  V3 should remain unchanged.  If Linux wants 
ReiserFS AND 4K stacks, they're going to have to wait for V4.

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Fri, 11 June 2004 10:31:35 -0400, Timothy Miller wrote:
> 
> Anyhow, I agree with you.  V3 should remain unchanged.  If Linux wants 
> ReiserFS AND 4K stacks, they're going to have to wait for V4.

Reiser3 appears to be safe with 4k stacks for the moment.

> From: Vladimir Saveliev <vs@namesys.com>
> [...]
> it will not be easy to make reiser4 to work with 4k stack

Reiser4 not.  What were you saying again? ;)

Jörn

-- 
It's not whether you win or lose, it's how you place the blame.
-- unknown

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Wed, 9 June 2004 10:06:16 -0700, Hans Reiser wrote:
> >
> Can you give me some background on whether this is causing real problems 
> for real users?

It's not [yet].  This was done with statical analysis and keeping a
little extra room for safety.  If you prefer to wait for real bug
reports, go ahead...

...but note that my signature ai has proven it's merits once again...

Jörn

-- 
...one more straw can't possibly matter...
-- Kirby Bakken

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Jörn Engel wrote:

>On Wed, 9 June 2004 10:06:16 -0700, Hans Reiser wrote:
>  
>
>>Can you give me some background on whether this is causing real problems 
>>for real users?
>>    
>>
>
>It's not [yet].  This was done with statical analysis and keeping a
>little extra room for safety.  If you prefer to wait for real bug
>reports, go ahead...
>
>...but note that my signature ai has proven it's merits once again...
>  
>
what is your signature ai?

>Jörn
>
>  
>
Unless it is really necessary, or a small code change, I would prefer to 
spend our cycles worrying about this in reiser4, because code changes in 
V3 are to be avoided if possible.

I am open to arguments that it is really necessary.

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Wed, 9 June 2004 11:09:55 -0700, Hans Reiser wrote:
> Jörn Engel wrote:
> >
> >...but note that my signature ai has proven it's merits once again...
> >
> what is your signature ai?

fortune.  It is clearly artificial and it's results prove high
intelligence sometimes. ;)

> Unless it is really necessary, or a small code change, I would prefer to 
> spend our cycles worrying about this in reiser4, because code changes in 
> V3 are to be avoided if possible.

Fair enough.

> I am open to arguments that it is really necessary.

The main argument is that you are already "this close" to the limit
and future code changes (in reiserfs or in unrelated functions called
before or after reiserfs) will blow said limit.

Since reiser3 won't get many changes anymore and other code should
generally get enhanced, rather than degraded, you should be pretty
safe.

Is there a simple way to tell reiser3 functions from reiser4, btw?
Something similar to ext2/ext3 would be nice.

Jörn

-- 
Beware of bugs in the above code; I have only proved it correct, but
not tried it.
-- Donald Knuth

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Jörn Engel wrote:

>
>
>Since reiser3 won't get many changes anymore and other code should
>generally get enhanced, rather than degraded, you should be pretty
>safe.
>
>Is there a simple way to tell reiser3 functions from reiser4, btw?
>  
>
They are in the reiser4 subdirectory....

>Something similar to ext2/ext3 would be nice.
>
>Jörn
>
>  
>

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Wed, 9 June 2004 16:42:50 -0700, Hans Reiser wrote:
> Jörn Engel wrote:
> 
> >Is there a simple way to tell reiser3 functions from reiser4, btw?
> > 
> They are in the reiser4 subdirectory....

Does that imply that one cannot build a kernel with both reiser3 and
reiser4 in it?  Or how do you make sure there are not name collisions,
being the namespace expert? ;)

Jörn

-- 
Data expands to fill the space available for storage.
-- Parkinson's Law

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Jörn Engel wrote:

>On Wed, 9 June 2004 16:42:50 -0700, Hans Reiser wrote:
>  
>
>>Jörn Engel wrote:
>>
>>    
>>
>>>Is there a simple way to tell reiser3 functions from reiser4, btw?
>>>
>>>      
>>>
>>They are in the reiser4 subdirectory....
>>    
>>
>
>Does that imply that one cannot build a kernel with both reiser3 and
>reiser4 in it? 
>
No.

> Or how do you make sure there are not name collisions,
>being the namespace expert? ;)
>  
>
Be consistently original.;-)

>Jörn
>
>  
>

Re: [STACK] >3k call path in reiserfs

[Chris Mason]

On Wed, 2004-06-09 at 14:09, Hans Reiser wrote:

> Unless it is really necessary, or a small code change, I would prefer to 
> spend our cycles worrying about this in reiser4, because code changes in 
> V3 are to be avoided if possible.
> 
> I am open to arguments that it is really necessary.

It's pretty important, especially when you toss NFS into the call path
the stack usage can go higher.  The switch to kmalloc will be relatively
small and by now we're good at testing for schedule bugs.

-chris

Re: [STACK] >3k call path in reiserfs

[Jörn Engel]

On Wed, 9 June 2004 14:48:54 -0400, Chris Mason wrote:
> 
> It's pretty important, especially when you toss NFS into the call path
> the stack usage can go higher.  The switch to kmalloc will be relatively
> small and by now we're good at testing for schedule bugs.

How can that happen?  Ignoring recursions, the data given should
already be the theoretical maximum.  Otherwise, please show me where
my tool makes a non-pessimistic choice.

[ Actually, I still miss callback functions.  Known bug. ]

Jörn

-- 
Public Domain  - Free as in Beer
General Public - Free as in Speech
BSD License    - Free as in Enterprise
Shared Source  - Free as in "Work will make you..."

Re: [STACK] >3k call path in reiserfs

[Hans Reiser]

Chris Mason wrote:

>On Wed, 2004-06-09 at 14:09, Hans Reiser wrote:
>
>  
>
>>Unless it is really necessary, or a small code change, I would prefer to 
>>spend our cycles worrying about this in reiser4, because code changes in 
>>V3 are to be avoided if possible.
>>
>>I am open to arguments that it is really necessary.
>>    
>>
>
>It's pretty important, especially when you toss NFS into the call path
>the stack usage can go higher.  The switch to kmalloc will be relatively
>small and by now we're good at testing for schedule bugs.
>
>-chris
>
>
>
>
>  
>
Performance impact of kmalloc?

Re: [STACK] >3k call path in reiserfs

[Vladimir Saveliev]

Hello

On Wed, 2004-06-09 at 22:09, Hans Reiser wrote:
> Jörn Engel wrote:
> 
> >On Wed, 9 June 2004 10:06:16 -0700, Hans Reiser wrote:
> >  
> >
> >>Can you give me some background on whether this is causing real problems 
> >>for real users?
> >>    
> >>
> >
> >It's not [yet].  This was done with statical analysis and keeping a
> >little extra room for safety.  If you prefer to wait for real bug
> >reports, go ahead...
> >
> >...but note that my signature ai has proven it's merits once again...
> >  
> >
> what is your signature ai?
> 
> >Jörn
> >
> >  
> >
> Unless it is really necessary, or a small code change, I would prefer to 
> spend our cycles worrying about this in reiser4, 

it will not be easy to make reiser4 to work with 4k stack

> because code changes in 
> V3 are to be avoided if possible.
> 
> I am open to arguments that it is really necessary.
>