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
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
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
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?
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
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
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"?
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.
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
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
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
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..."
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.
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
>
>
>
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?
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.
>
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
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
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
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
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
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.
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 <[email protected]>
> [...]
> 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
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
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
>
>
>
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
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
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
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
>
>
>
>
>
>