Re: top stack (l)users for 2.5.67

Re: top stack (l)users for 2.5.67

[Alan Cox]

On Llu, 2003-04-14 at 18:30, Jörn Engel wrote:
> Is intermezzo still actively maintained? I submitted patches for those
> two presto-functions several weeks ago and didn't notice any feedback.

I've found the maintainers slow but its not their major project any
more. Feed them into -ac if you want

Re: top stack (l)users for 2.5.67

[Jörn Engel]

2.5 seems to be getting some driver care, lately. Compared to 2.5.64,
far less drivers were removed after make allyesconfig.

Again, all functions using >1k stack frame on i386.

44 functions for .67, .64 still had 51, things are getting better here
as well.

Is intermezzo still actively maintained? I submitted patches for those
two presto-functions several weeks ago and didn't notice any feedback.

0xc0221fe6 presto_get_fileid:                            sub    $0x1194,%esp
0xc02209a6 presto_copy_kml_tail:                         sub    $0x1028,%esp
0xc099bd9d gdth_ioctl:                                   sub    $0xb7c,%esp
0xc08f2548 ide_unregister:                               sub    $0x988,%esp
0xc082d9ab v4l_compat_translate_ioctl:                   sub    $0x8d4,%esp
0xc08b3743 ia_ioctl:                                     sub    $0x84c,%esp
0xc0e4a013 snd_emu10k1_fx8010_ioctl:                     sub    $0x830,%esp
0xc084c6c6 w9966_v4l_read:                               sub    $0x828,%esp
0xc0ddb53b snd_cmipci_ac3_copy:                          sub    $0x7c0,%esp
0xc0ddbb5b snd_cmipci_ac3_silence:                       sub    $0x7c0,%esp
0xc0aa10c8 amd_flash_probe:                              sub    $0x72c,%esp
0xc0105650 huft_build:                                   sub    $0x59c,%esp
0xc01073d0 huft_build:                                   sub    $0x59c,%esp
0xc02d9c56 dohash:                                       sub    $0x594,%esp
0xc0108256 inflate_dynamic:                              sub    $0x554,%esp
0xc05e2733 ida_ioctl:                                    sub    $0x54c,%esp
0xc01064a6 inflate_dynamic:                              sub    $0x538,%esp
0xc0fb00e3 device_new_if:                                sub    $0x520,%esp
0xc0216b86 presto_ioctl:                                 sub    $0x508,%esp
0xc0e44368 snd_emu10k1_add_controls:                     sub    $0x4dc,%esp
0xc0e68646 snd_trident_mixer:                            sub    $0x4b4,%esp
0xc0106307 inflate_fixed:                                sub    $0x4ac,%esp
0xc01080b7 inflate_fixed:                                sub    $0x4ac,%esp
0xc0909bc1 ide_config:                                   sub    $0x4a8,%esp
0xc0f9d5db br_ioctl_device:                              sub    $0x498,%esp
0xc05c6bbc parport_config:                               sub    $0x490,%esp
0xc0bec486 sw_connect:                                   sub    $0x490,%esp
0xc0c105c3 ixj_config:                                   sub    $0x484,%esp
0xc0bf3011 uinput_alloc_device:                          sub    $0x480,%esp
0xc10b3d76 sctp_hash_digest:                             sub    $0x45c,%esp
0xc103e443 gss_pipe_downcall:                            sub    $0x450,%esp
0xc03b1268 ciGetLeafPrefixKey:                           sub    $0x428,%esp
0xc0454b53 befs_error:                                   sub    $0x418,%esp
0xc0454bc3 befs_warning:                                 sub    $0x418,%esp
0xc0454c33 befs_debug:                                   sub    $0x418,%esp
0xc07b1256 wv_hw_reset:                                  sub    $0x414,%esp
0xc16bcec5 root_nfs_name:                                sub    $0x414,%esp
0xc0c37b42 bt3c_config:                                  sub    $0x410,%esp
0xc0c3bcc2 btuart_config:                                sub    $0x410,%esp
0xc076cb71 hex_dump:                                     sub    $0x40c,%esp
0xc0326c17 jffs2_rtime_compress:                         sub    $0x408,%esp
0xc0c360ff dtl1_config:                                  sub    $0x408,%esp
0xc0c39f56 bluecard_config:                              sub    $0x408,%esp
0xc0326d15 jffs2_rtime_decompress:                       sub    $0x404,%esp

Jörn

-- 
Measure. Don't tune for speed until you've measured, and even then
don't unless one part of the code overwhelms the rest.
-- Rob Pike

Re: top stack (l)users for 2.5.67

[Jörn Engel]

On Mon, 14 April 2003 17:37:55 +0100, Alan Cox wrote:
> On Llu, 2003-04-14 at 18:30, Jörn Engel wrote:
> > Is intermezzo still actively maintained? I submitted patches for those
> > two presto-functions several weeks ago and didn't notice any feedback.
> 
> I've found the maintainers slow but its not their major project any
> more. Feed them into -ac if you want

Sure, the below was against 2.5.64 and applies cleanly to .67.

Jörn

-- 
Do not stop an army on its way home.
-- Sun Tzu

--- linux-2.5.64/fs/intermezzo/journal.c	Mon Feb 24 20:05:05 2003
+++ linux-2.5.64-i2o/fs/intermezzo/journal.c	Fri Mar 14 17:37:18 2003
@@ -1239,12 +1239,15 @@
         return izo_rcvd_write(fset, &rec);
 }
 
+/* FIXME: should the below go into some header file? */
+#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
 struct file * presto_copy_kml_tail(struct presto_file_set *fset,
                                    unsigned long int start)
 {
         struct file *f;
         int len;
         loff_t read_off, write_off, bytes;
+        char *buf;
 
         ENTRY;
 
@@ -1255,15 +1258,18 @@
                 return f;
         }
 
+        buf = kmalloc(PRESTO_COPY_KML_TAIL_BUFSIZE, GFP_KERNEL);
+        if (!buf)
+                return ERR_PTR(-ENOMEM);
+
         write_off = 0;
         read_off = start;
         bytes = fset->fset_kml.fd_offset - start;
         while (bytes > 0) {
-                char buf[4096];
                 int toread;
 
-                if (bytes > sizeof(buf))
-                        toread = sizeof(buf);
+                if (bytes > PRESTO_COPY_KML_TAIL_BUFSIZE)
+                        toread = PRESTO_COPY_KML_TAIL_BUFSIZE;
                 else
                         toread = bytes;
 
@@ -1274,6 +1280,7 @@
 
                 if (presto_fwrite(f, buf, len, &write_off) != len) {
                         filp_close(f, NULL);
+                        kfree(buf);
                         EXIT;
                         return ERR_PTR(-EIO);
                 }
@@ -1281,6 +1288,7 @@
                 bytes -= len;
         }
 
+        kfree(buf);
         EXIT;
         return f;
 }
@@ -1584,12 +1592,14 @@
         return error;
 }
 
+/* FIXME: should the below go into some header file? */
+#define PRESTO_GET_FILEID_BUFSIZE 4096
 int presto_get_fileid(int minor, struct presto_file_set *fset,
                       struct dentry *dentry)
 {
         int opcode = KML_OPCODE_GET_FILEID;
         struct rec_info rec;
-        char *buffer, *path, *logrecord, record[4096]; /*include path*/
+        char *buffer, *path, *logrecord, *record; /*include path*/
         struct dentry *root;
         __u32 uid, gid, pathlen;
         int error, size;
@@ -1597,6 +1607,10 @@
 
         ENTRY;
 
+        record = kmalloc(PRESTO_GET_FILEID_BUFSIZE, GFP_KERNEL);
+        if (!record)
+                return -ENOMEM;
+
         root = fset->fset_dentry;
 
         uid = cpu_to_le32(dentry->d_inode->i_uid);
@@ -1610,7 +1624,7 @@
                 sizeof(struct kml_suffix);
 
         CDEBUG(D_FILE, "kml size: %d\n", size);
-        if ( size > sizeof(record) )
+        if ( size > PRESTO_GET_FILEID_BUFSIZE )
                 CERROR("InterMezzo: BUFFER OVERFLOW in %s!\n", __FUNCTION__);
 
         memset(&rec, 0, sizeof(rec));
@@ -1633,6 +1647,7 @@
                                    fset->fset_name);
 
         BUFF_FREE(buffer);
+        kfree(record);
         EXIT;
         return error;
 }

Re: top stack (l)users for 2.5.67

[Dave Jones]

On Mon, Apr 14, 2003 at 07:46:45PM +0200, J?rn Engel wrote:

 > +/* FIXME: should the below go into some header file? */
 > +#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
 >  struct file * presto_copy_kml_tail(struct presto_file_set *fset,
 >                                     unsigned long int start)
 >  {

so, presto_copy_kml_tail() is only called from
presto_finish_kml_truncate(), which doesn't seem to be called
from anywhere. What am I missing here? Or can this whole lot
just be nuked ?

If not, this patch introduces a problem.  You're now
calling a sleeping function (kmalloc) whilst holding
a lock according to the comment above presto_finish_kml_truncate()

		Dave

Re: top stack (l)users for 2.5.67

[Jörn Engel]

On Mon, 14 April 2003 19:25:53 +0100, Dave Jones wrote:
> On Mon, Apr 14, 2003 at 07:46:45PM +0200, J?rn Engel wrote:
> 
>  > +/* FIXME: should the below go into some header file? */
>  > +#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
>  >  struct file * presto_copy_kml_tail(struct presto_file_set *fset,
>  >                                     unsigned long int start)
>  >  {
> 
> so, presto_copy_kml_tail() is only called from
> presto_finish_kml_truncate(), which doesn't seem to be called
> from anywhere. What am I missing here? Or can this whole lot
> just be nuked ?

No idea. I'm just trying to get the kernel into a state where the
kernel stack can be reduced to 4k relatively safely.
As far as intermezzo is concerned, I've never even heard of someone
using it and care accordingly.

> If not, this patch introduces a problem.  You're now
> calling a sleeping function (kmalloc) whilst holding
> a lock according to the comment above presto_finish_kml_truncate()

Ack. Would it be ok to malloc with GFP_ATOMIC then, or would you
propose something different?

Jörn

-- 
ticks = jiffies;
while (ticks == jiffies);
ticks = jiffies;
-- /usr/src/linux/init/main.c

Re: top stack (l)users for 2.5.67

[Andreas Dilger]

On Apr 14, 2003  21:05 +0200, Jörn Engel wrote:
> On Mon, 14 April 2003 19:25:53 +0100, Dave Jones wrote:
> > On Mon, Apr 14, 2003 at 07:46:45PM +0200, J?rn Engel wrote:
> >  > +/* FIXME: should the below go into some header file? */
> >  > +#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
> >  >  struct file * presto_copy_kml_tail(struct presto_file_set *fset,
> >  >                                     unsigned long int start)
> >  >  {
> > 
> > so, presto_copy_kml_tail() is only called from
> > presto_finish_kml_truncate(), which doesn't seem to be called
> > from anywhere. What am I missing here? Or can this whole lot
> > just be nuked ?
> 
> No idea. I'm just trying to get the kernel into a state where the
> kernel stack can be reduced to 4k relatively safely.
> As far as intermezzo is concerned, I've never even heard of someone
> using it and care accordingly.
> 
> > If not, this patch introduces a problem.  You're now
> > calling a sleeping function (kmalloc) whilst holding
> > a lock according to the comment above presto_finish_kml_truncate()
> 
> Ack. Would it be ok to malloc with GFP_ATOMIC then, or would you
> propose something different?

I've CC'd the InterMezzo mailing list (which is where the maintainers of
this code live).  Could someone please post a copy of the original patch
to the intermezzo-devel@lists.sourceforge.net mailing list?

Actually, my recollection is that there was previously a patch posted
for fixing this large stack usage the last time this came up.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: top stack (l)users for 2.5.67

[Randy.Dunlap]

On Mon, 14 Apr 2003 19:30:47 +0200 Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:


| 0xc05e2733 ida_ioctl:                                    sub    $0x54c,%esp

patch posted 2003.APR.03 (on lkml); Steve Cameron saw it...

| 0xc0fb00e3 device_new_if:                                sub    $0x520,%esp

patch posted 2003.APR.03 (on linux-net);
no reply from Nenad Corbic (ncorbic@sangoma.com)


--
~Randy

Re: top stack (l)users for 2.5.67

[Jörn Engel]

On Mon, 14 April 2003 13:18:52 -0600, Andreas Dilger wrote:
> 
> I've CC'd the InterMezzo mailing list (which is where the maintainers of
> this code live).  Could someone please post a copy of the original patch
> to the intermezzo-devel@lists.sourceforge.net mailing list?

Attached. (Yes, this is a duplicate for lkml, but it's not that big)

> Actually, my recollection is that there was previously a patch posted
> for fixing this large stack usage the last time this came up.

Yup, I already tried this once before and got some feedback. Just none
from braam@clusterfs.com, who is the contact according to MAINTAINERS.
Should I update that file to intermezzo-devel@lists.sourceforge.net?

Jörn

-- 
With a PC, I always felt limited by the software available. On Unix, 
I am limited only by my knowledge.
-- Peter J. Schoenster

--- linux-2.5.64/fs/intermezzo/journal.c	Mon Feb 24 20:05:05 2003
+++ linux-2.5.64-i2o/fs/intermezzo/journal.c	Fri Mar 14 17:37:18 2003
@@ -1239,12 +1239,15 @@
         return izo_rcvd_write(fset, &rec);
 }
 
+/* FIXME: should the below go into some header file? */
+#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
 struct file * presto_copy_kml_tail(struct presto_file_set *fset,
                                    unsigned long int start)
 {
         struct file *f;
         int len;
         loff_t read_off, write_off, bytes;
+        char *buf;
 
         ENTRY;
 
@@ -1255,15 +1258,18 @@
                 return f;
         }
 
+        buf = kmalloc(PRESTO_COPY_KML_TAIL_BUFSIZE, GFP_KERNEL);
+        if (!buf)
+                return ERR_PTR(-ENOMEM);
+
         write_off = 0;
         read_off = start;
         bytes = fset->fset_kml.fd_offset - start;
         while (bytes > 0) {
-                char buf[4096];
                 int toread;
 
-                if (bytes > sizeof(buf))
-                        toread = sizeof(buf);
+                if (bytes > PRESTO_COPY_KML_TAIL_BUFSIZE)
+                        toread = PRESTO_COPY_KML_TAIL_BUFSIZE;
                 else
                         toread = bytes;
 
@@ -1274,6 +1280,7 @@
 
                 if (presto_fwrite(f, buf, len, &write_off) != len) {
                         filp_close(f, NULL);
+                        kfree(buf);
                         EXIT;
                         return ERR_PTR(-EIO);
                 }
@@ -1281,6 +1288,7 @@
                 bytes -= len;
         }
 
+        kfree(buf);
         EXIT;
         return f;
 }
@@ -1584,12 +1592,14 @@
         return error;
 }
 
+/* FIXME: should the below go into some header file? */
+#define PRESTO_GET_FILEID_BUFSIZE 4096
 int presto_get_fileid(int minor, struct presto_file_set *fset,
                       struct dentry *dentry)
 {
         int opcode = KML_OPCODE_GET_FILEID;
         struct rec_info rec;
-        char *buffer, *path, *logrecord, record[4096]; /*include path*/
+        char *buffer, *path, *logrecord, *record; /*include path*/
         struct dentry *root;
         __u32 uid, gid, pathlen;
         int error, size;
@@ -1597,6 +1607,10 @@
 
         ENTRY;
 
+        record = kmalloc(PRESTO_GET_FILEID_BUFSIZE, GFP_KERNEL);
+        if (!record)
+                return -ENOMEM;
+
         root = fset->fset_dentry;
 
         uid = cpu_to_le32(dentry->d_inode->i_uid);
@@ -1610,7 +1624,7 @@
                 sizeof(struct kml_suffix);
 
         CDEBUG(D_FILE, "kml size: %d\n", size);
-        if ( size > sizeof(record) )
+        if ( size > PRESTO_GET_FILEID_BUFSIZE )
                 CERROR("InterMezzo: BUFFER OVERFLOW in %s!\n", __FUNCTION__);
 
         memset(&rec, 0, sizeof(rec));
@@ -1633,6 +1647,7 @@
                                    fset->fset_name);
 
         BUFF_FREE(buffer);
+        kfree(record);
         EXIT;
         return error;
 }

Re: top stack (l)users for 2.5.67

[Jörn Engel]

On Mon, 14 April 2003 12:38:10 -0700, Randy.Dunlap wrote:
> On Mon, 14 Apr 2003 19:30:47 +0200 Jörn Engel <joern@wohnheim.fh-wedel.de> wrote:
> 
> 
> | 0xc05e2733 ida_ioctl:                                    sub    $0x54c,%esp
> 
> patch posted 2003.APR.03 (on lkml); Steve Cameron saw it...
> 
> | 0xc0fb00e3 device_new_if:                                sub    $0x520,%esp
> 
> patch posted 2003.APR.03 (on linux-net);
> no reply from Nenad Corbic (ncorbic@sangoma.com)

Hm, all these stack reduction patches are relevant to -je as well.
Could I have a copy of those two?

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: top stack (l)users for 2.5.67

[Jörn Engel]

On Tue, 15 April 2003 09:38:49 -0600, Peter Braam wrote:
> 
> Yes please update the email/contact to intermezzo-devel@lists.sf.net.
> Chen Yang is maintaining the code and he can give nods of approval
> when required.

Like this?

Jörn

-- 
Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface. 
-- Doug MacIlroy

--- linux-2.5.67/MAINTAINERS~intermezzo_maintain	2003-04-07 19:31:49.000000000 +0200
+++ linux-2.5.67/MAINTAINERS	2003-04-15 11:01:57.000000000 +0200
@@ -931,8 +931,8 @@
 S:	Supported
 
 INTERMEZZO FILE SYSTEM
-P:	Peter J. Braam
-M:	braam@clusterfs.com
+P:	Chen Yang
+M:	intermezzo-devel@lists.sf.net
 W:	http://www.inter-mezzo.org/
 L:	intermezzo-discuss@lists.sourceforge.net
 S:	Maintained

Re: top stack (l)users for 2.5.67

[Peter Braam]

Yes please update the email/contact to intermezzo-devel@lists.sf.net.
Chen Yang is maintaining the code and he can give nods of approval
when required.

- Peter -



On Mon, Apr 14, 2003 at 09:40:24PM +0200, Jörn Engel wrote:
> On Mon, 14 April 2003 13:18:52 -0600, Andreas Dilger wrote:
> > 
> > I've CC'd the InterMezzo mailing list (which is where the maintainers of
> > this code live).  Could someone please post a copy of the original patch
> > to the intermezzo-devel@lists.sourceforge.net mailing list?
> 
> Attached. (Yes, this is a duplicate for lkml, but it's not that big)
> 
> > Actually, my recollection is that there was previously a patch posted
> > for fixing this large stack usage the last time this came up.
> 
> Yup, I already tried this once before and got some feedback. Just none
> from braam@clusterfs.com, who is the contact according to MAINTAINERS.
> Should I update that file to intermezzo-devel@lists.sourceforge.net?
> 
> Jörn
> 
> -- 
> With a PC, I always felt limited by the software available. On Unix, 
> I am limited only by my knowledge.
> -- Peter J. Schoenster
> 
> --- linux-2.5.64/fs/intermezzo/journal.c	Mon Feb 24 20:05:05 2003
> +++ linux-2.5.64-i2o/fs/intermezzo/journal.c	Fri Mar 14 17:37:18 2003
> @@ -1239,12 +1239,15 @@
>          return izo_rcvd_write(fset, &rec);
>  }
>  
> +/* FIXME: should the below go into some header file? */
> +#define PRESTO_COPY_KML_TAIL_BUFSIZE 4096
>  struct file * presto_copy_kml_tail(struct presto_file_set *fset,
>                                     unsigned long int start)
>  {
>          struct file *f;
>          int len;
>          loff_t read_off, write_off, bytes;
> +        char *buf;
>  
>          ENTRY;
>  
> @@ -1255,15 +1258,18 @@
>                  return f;
>          }
>  
> +        buf = kmalloc(PRESTO_COPY_KML_TAIL_BUFSIZE, GFP_KERNEL);
> +        if (!buf)
> +                return ERR_PTR(-ENOMEM);
> +
>          write_off = 0;
>          read_off = start;
>          bytes = fset->fset_kml.fd_offset - start;
>          while (bytes > 0) {
> -                char buf[4096];
>                  int toread;
>  
> -                if (bytes > sizeof(buf))
> -                        toread = sizeof(buf);
> +                if (bytes > PRESTO_COPY_KML_TAIL_BUFSIZE)
> +                        toread = PRESTO_COPY_KML_TAIL_BUFSIZE;
>                  else
>                          toread = bytes;
>  
> @@ -1274,6 +1280,7 @@
>  
>                  if (presto_fwrite(f, buf, len, &write_off) != len) {
>                          filp_close(f, NULL);
> +                        kfree(buf);
>                          EXIT;
>                          return ERR_PTR(-EIO);
>                  }
> @@ -1281,6 +1288,7 @@
>                  bytes -= len;
>          }
>  
> +        kfree(buf);
>          EXIT;
>          return f;
>  }
> @@ -1584,12 +1592,14 @@
>          return error;
>  }
>  
> +/* FIXME: should the below go into some header file? */
> +#define PRESTO_GET_FILEID_BUFSIZE 4096
>  int presto_get_fileid(int minor, struct presto_file_set *fset,
>                        struct dentry *dentry)
>  {
>          int opcode = KML_OPCODE_GET_FILEID;
>          struct rec_info rec;
> -        char *buffer, *path, *logrecord, record[4096]; /*include path*/
> +        char *buffer, *path, *logrecord, *record; /*include path*/
>          struct dentry *root;
>          __u32 uid, gid, pathlen;
>          int error, size;
> @@ -1597,6 +1607,10 @@
>  
>          ENTRY;
>  
> +        record = kmalloc(PRESTO_GET_FILEID_BUFSIZE, GFP_KERNEL);
> +        if (!record)
> +                return -ENOMEM;
> +
>          root = fset->fset_dentry;
>  
>          uid = cpu_to_le32(dentry->d_inode->i_uid);
> @@ -1610,7 +1624,7 @@
>                  sizeof(struct kml_suffix);
>  
>          CDEBUG(D_FILE, "kml size: %d\n", size);
> -        if ( size > sizeof(record) )
> +        if ( size > PRESTO_GET_FILEID_BUFSIZE )
>                  CERROR("InterMezzo: BUFFER OVERFLOW in %s!\n", __FUNCTION__);
>  
>          memset(&rec, 0, sizeof(rec));
> @@ -1633,6 +1647,7 @@
>                                     fset->fset_name);
>  
>          BUFF_FREE(buffer);
> +        kfree(record);
>          EXIT;
>          return error;
>  }
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> intermezzo-devel mailing list
> intermezzo-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/intermezzo-devel
- Peter -