[Bug 198168] tail a FiFo: high IVCSW after first echo: 100% load

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198168

            Bug ID: 198168
           Summary: tail a FiFo: high IVCSW after first echo: 100% load
           Product: Base System
           Version: 10.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: kalten at gmx.at

Created attachment 153665
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=153665&action=edit
truss tail -f TestFiFo

Greetings!

I have stumbled over one very interesting problem on amd64 10.0-p18 as well
as on amd64 10.1-p6.

The shortest reconstruction I can present to you is as follows:

In one terminal:
$ mkfifo TestFiFo
$ tail -f TestFiFo

(and the manual page of tail(1) allows »tail -f« of a fifo)

In a second terminal let us start good old top(1). Use <a>-key to toggle
the displaying of process parameters (that way, we can find our tail more
easily). Our tail process should not do much.

Now in a third terminal:
$ echo "I am some input" >> TestFiFo

We can see the text in our first terminal displayed by tail.

But: the load of that tail rises up to 100%; switching to io mode by
pressing the <m>-key in top shows us, that IVCSW rises to the sky;
furthermore the used cpu changes all the time.

The manual page does not state what IVCSW stands for, but in this article
http://lists.freebsd.org/pipermail/freebsd-questions/2007-September/158479.html
we are told: “IVCSW = 'Involuntary context switches'”.

I had a look at the output of truss(1). You can find the output of
»truss tail -f TestFiFo« in the attachment. (I did hit C-c at some point)
After writing our test text to the screen, the following happens:
---8<---
madvise(0x80100d000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffd650,0x800bc8be0) =
0 (0x0)
madvise(0x80101d000,0x1000,0x5,0xaaaaaaaaaaaaaaab,0x7fffffffd650,0x800bc8be0) =
0 (0x0)
kqueue(0x800b9fbc0,0x7fffffffffffc,0x0,0x0,0x9,0x3a8) = 4 (0x4)
fstatfs(0x3,0x7fffffffdfb8,0x1,0x800624330,0x2,0x80100d010) = 0 (0x0)
kevent(4,{0x3,EVFILT_READ,EV_ADD|EV_ENABLE|EV_CLEAR,0,0x0,0x0},1,0x0,0,{0.000000000
}) = 0 (0x0)
kevent(4,0x0,0,{0x3,EVFILT_READ,EV_CLEAR|EV_EOF,0,0x0,0x0},1,0x0) = 1 (0x1)
read(3,0x801009000,16384)             = 0 (0x0)
kevent(4,0x0,0,{0x3,EVFILT_READ,EV_CLEAR|EV_EOF,0,0x0,0x0},1,0x0) = 1 (0x1)
read(3,0x801009000,16384)             = 0 (0x0)
kevent(4,0x0,0,{0x3,EVFILT_READ,EV_CLEAR|EV_EOF,0,0x0,0x0},1,0x0) = 1 (0x1)
read(3,0x801009000,16384)             = 0 (0x0)
--->8---
repeating those last two lines over and over again.

I think, that is quite some interesting bug ;-)

(Could it be related to the closed Bug 23099 Comment 2 form the year 2000
in some way? As »cat TestFiFo« closes after the echo-command, I assume,
that EOF is sent?)

Regards,
 Kalten

-- 
You are receiving this mail because:
You are the assignee for the bug.