All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Michael Kerrisk <mtk-manpages@gmx.net>
Cc: lcapitulino@mandriva.com.br, vendor-sec@lst.de,
	linux-kernel@vger.kernel.org, akpm@osdl.org,
	michael.kerrisk@gmx.net
Subject: Re: splice/tee bugs?
Date: Mon, 10 Jul 2006 10:46:46 +0200	[thread overview]
Message-ID: <20060710084645.GJ4141@suse.de> (raw)
In-Reply-To: <20060710084017.109310@gmx.net>

On Mon, Jul 10 2006, Michael Kerrisk wrote:
> > > One slight strangeness.  Most of the time, the 
> > > "find . | ktee r | wc" command line takes about 0.1 seconds to 
> > > execute, but about 1 time in 5 on my x86 system, it takes about 
> > > 1.5 to 2 seconds to execute.  Any ideas about what's happening 
> > > there?
> > 
> > That is pretty odd. Any chance you can do a quick sysrq-t and see where
> > find/ktee/wc is stuck when this happens? You should not be seeing that,
> > naturally, I'll see if I can reproduce that here. How much data does
> > find . return in your example?
> 
> See the start of this message.
> 
> One sysrq-t output output below.
> 
> Cheers,
> 
> Michael
> 
> 
> find          D B9099C00     0 14170   4167         14171       (NOTLB)
>    ca279d04 00118054 00000008 b9099c00 003d0ca2 e7b0b9f8 00000009 d307f688
>    d307f580 c0459dc0 c1507620 b9099c00 003d0ca2 00000000 00000000 00118054
>    00000001 00001000 c015010e e647f5ac e647f5b8 00000046 00000000 00000000
> Call Trace:
>  <c015010e> __getblk+0x1d/0x225
>  <c03e1e7c> io_schedule+0x26/0x30
>  <c0150874> sync_buffer+0x37/0x3a
>  <c03e25fd> __wait_on_bit+0x33/0x59
>  <c015083d> sync_buffer+0x0/0x3a
>  <c03e2695> out_of_line_wait_on_bit+0x72/0x7a
>  <c015083d> sync_buffer+0x0/0x3a
>  <c0127dd5> wake_bit_function+0x0/0x34
>  <c019e39b> search_by_key+0x133/0xd91
>  <c0110a1c> do_page_fault+0x0/0x532
>  <c0189e2d> search_by_entry_key+0x20/0x22f
>  <c015dc76> filldir64+0x8e/0xc3
>  <c019e214> pathrelse+0x1b/0x2f
>  <c019388c> reiserfs_readdir+0x3e3/0x3fb
>  <c0193895> reiserfs_readdir+0x3ec/0x3fb
>  <c018d6e5> reiserfs_update_sd_size+0x67/0x24c
>  <c01a55c9> journal_begin+0x9c/0xdc
>  <c0196cb0> reiserfs_dirty_inode+0x5a/0x76
>  <c016bacc> __mark_inode_dirty+0x2d/0x15e
>  <c015dd9a> vfs_readdir+0x58/0x6f
>  <c015de14> sys_getdents64+0x63/0xa8
>  <c015dbe8> filldir64+0x0/0xc3
>  <c010287f> syscall_call+0x7/0xb

So it's find being stuck, this doesn't look tee/splice related at all.
Can you reproduce the same thing just by doing the find . > /dev/null?

-- 
Jens Axboe


  reply	other threads:[~2006-07-10  8:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-07  7:07 splice/tee bugs? Michael Kerrisk
2006-07-07 11:07 ` Andrew Morton
2006-07-07 11:42   ` Michael Kerrisk
2006-07-07 12:03     ` Jens Axboe
2006-07-07 12:28       ` Jens Axboe
2006-07-07 12:31         ` Michael Kerrisk
2006-07-07 12:41           ` Jens Axboe
2006-07-07 13:12             ` Jens Axboe
2006-07-07 13:14               ` Jens Axboe
2006-07-07 13:21                 ` Arjan van de Ven
2006-07-07 13:26                   ` Jens Axboe
2006-07-07 13:54                     ` Paulo Marques
2006-07-07 14:02                       ` Jens Axboe
2006-07-07 14:05               ` Michael Kerrisk
2006-07-07 14:08                 ` Jens Axboe
2006-07-07 16:13   ` Luiz Fernando N. Capitulino
2006-07-07 21:43     ` Luiz Fernando N. Capitulino
2006-07-08  6:41     ` Jens Axboe
2006-07-08 21:09       ` Luiz Fernando N. Capitulino
2006-07-09 10:36         ` Jens Axboe
2006-07-09 11:16           ` Jens Axboe
2006-07-09 16:47             ` Luiz Fernando N. Capitulino
2006-07-09 17:57               ` Jens Axboe
2006-07-10  6:25                 ` Michael Kerrisk
2006-07-10  6:43                   ` Jens Axboe
2006-07-10  8:09                     ` Michael Kerrisk
2006-07-10  8:24                       ` Jens Axboe
2006-07-10  8:40                         ` Michael Kerrisk
2006-07-10  8:46                           ` Jens Axboe [this message]
2006-07-10  8:50                             ` Michael Kerrisk
2006-07-10  9:06                               ` Jens Axboe
2006-07-10  9:08                                 ` Michael Kerrisk
2006-07-10  8:50                             ` Jens Axboe
  -- strict thread matches above, loose matches on Subject: below --
2006-07-08  5:33 Chuck Ebbert

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=20060710084645.GJ4141@suse.de \
    --to=axboe@suse.de \
    --cc=akpm@osdl.org \
    --cc=lcapitulino@mandriva.com.br \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.kerrisk@gmx.net \
    --cc=mtk-manpages@gmx.net \
    --cc=vendor-sec@lst.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.