From: gt0178a@prism.gatech.EDU (Jim Burns) Subject: Re: porting screen3.2: possible kernel/library bugs? Date: 26 May 1992 10:33:49 GMT
Thanx muchly to Linus, Branko Lankester, Theodore Ts'o, and Paul Hargrove
for posting or mailing. Their solutions fix 95% of my problems. Theodore
posted some kernel patches (Branko mentions the need for them also). Linus,
when will these make it into a distribution version? I will also be testing
out Paul's FIFO patches. Since Branko only mailed, I hope he doesn't mind
my posting his reply at the end of this article.
in article <1992May25.092323.8195@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) says:
>>Q1) are select() and COW working well?
> COW - yes, select() don't know. You don't mention which kernel you are
> running, but select() shouldn't be a problem on 0.96. X uses select()
> all the time, and I certainly don't see the above kinds of problems.
Actually, the more I think of it, COW only applies to child procs from a
fork(2). More generally, I meant shared text, which linux is also supposed
to have. However, if you are getting 2M of shared text w/X, I guess it's
working! Maybe bash (mcc-interim 0.95c+) isn't a good example.
I'm using 0.96a source re-configured for 16 ptys. I have 4M memory.
> I think both your problems are due to memory limitations: gcc certainly
> starts to crawl when memory gets tight, and linux starts discarding
> clean (ie code) pages. Note that linux doesn't give the signal 11 at
Ouch! I'll test this out w/an equivalent amount of memory in use by
something other than screen. However, it bothers me that SCREEN shows about
2.4% CPU usage in top(1), even while just doing do_select.
> try to keep only dirty pages in memory. In fact enabling swapping can
> /improve/ performance in this kind of circumstance: that gives linux a
> chance to swap out dirty pages, and give more room to code-pages that
> otherwise would have to be on disk.
Since I've never been able to get swapping to a file to work on my AHA1542B
setup, but recent posts from people w/the same setup say 0.96a fixes this,
I'll try this also. I haven't gotten around to re-checking in 0.96a.
> I haven't got the setreuid manual, and it seems there is a bug in the
> kernel. I'll have to check it out eventually.
Theodore posted the patch. I'm using the man pages from tsx-11. From my
previous post:
> (on tsx-11.mit.edu:pub/linux, get sources/{man-1.0,man}.tar.Z &
> docs/man/man2.shar.Z) work fine. Note, I recently noticed a problem w/
Date: Mon, 25 May 1992 11:13:23 +0200
From: lankeste@fwi.uva.nl (Branko Lankester)
X-Fax: +31 20 525 7490
X-Telex: 10262 hef nl
X-Phone: +31 20 525 7463
To: gt0178a@prism.gatech.EDU
Subject: Re: working on FIFOs for Linux 0.96
Newsgroups: comp.os.linux
Status: R
In comp.os.linux you write:
>which creates FIFOs just fine for root. Are you saying that the FIFO isn't
>usable? That would explain why when screen 3.2 detaches from the console,
>it can't reattach. (I will post more about screen(1) as I work some of the
>bugs out, but basically it is a performance hog. Also, is there any reason
>why setreuid(2) wouldn't work ?)
Named pipes don't work, the aren't implemented in the kernel. I compiled screen
so that it uses sockets, works very well. Only if you try to run it as non-root
there are some problems: setreuid() has a bug that doesn't let you set uid's
to 0, replace the two ">0"s in sys_setreuid() in kernel/sys.c with ">=0". Then
there is the problem that if linux creates sockets they are always owned by root,
I fixed this by changing the uid in the inode to the current euid after the call
to sys_mknod() (net/unix.c).
[and my part of my reply]:
I'm impressed - not only did you have my answers, but you've even played w/
screen under linux, so you knew what I was talking about!
I'll implement your fixes, but any idea when Linus will integrate them, and
named pipes, into the kernel? When I set the socket inode uid, do I use
geteuid() to get it - ie: is that a safe call in the kernel? Or is there a
struct I can use to find it? I haven't hacked the kernel, yet.
Since we don't have nlist.h, can't use LOADAV_*. When will this make it
into linux?
Much thanx for your input.
--
BURNS,JIM (returned student)
Georgia Institute of Technology, 30178 Georgia Tech Station,
Atlanta Georgia, 30332 | Internet: gt0178a@prism.gatech.edu
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a