From: | "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx> |
Date: | Wed, 11 Aug 2004 00:04:54 +0200 |
Second bug:
No wonder why my pppd is taking a lot of CPU time, just look at this(output from command ktrace -p 899 ;sleep 5; ktrace -C; kdump -R):
899 pppd 1092167829.271917 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000095 RET select 1
899 pppd 0.000014 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000024 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000012 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000013 RET select 1
899 pppd 0.000011 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000014 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000011 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000013 RET select 1
899 pppd 0.000011 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000013 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000012 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000013 RET select 1
899 pppd 0.000010 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000014 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000011 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000047 RET select 1
899 pppd 0.000012 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000015 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000011 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000014 RET select 1
899 pppd 0.000011 CALL read(0x5,0x8062180,0x5e0)
899 pppd 0.000014 RET read -1 errno 35 Resource temporarily unavailable
899 pppd 0.000011 CALL select(0x6,0xbfbffa10,0,0xbfbffa10,0)
899 pppd 0.000012 RET select 1
899 pppd 0.000011 CALL read(0x5,0x8062180,0x5e0)
[342376 lines of this in 5 seconds, the output file is 20mb in size.]
I have no idea what I'm talking about, so it might be total rubbish, but here is my current understanding of what is happenning:
pppd calls standard c library function select(), everything is OK, and it returns 1 which is the number of descriptors ready to be accessed. But when the returned file descriptor is read, it cannot be accessed because its unavailable. So it retries, gets an error, and keeps on retrying all the time at around 34000 times a second (assuming that there are 2 calls: select and read, and they are repeated around 170000 times for duration of 5 seconds, and thats 34000 select() and read() per second!).
I'm not very good programmer(hell, I cannot even be called a newbie programmer). But here are possible solution:
o find out why select() returns a invalid file descriptor o If its valid, find out why it becomes unavailable o Restrict on how often retry() gets called.
int read_packet(buf) u_char *buf; { int len;
if ((len = read(ttyfd, buf, PPP_MTU + PPP_HDRLEN)) < 0) { if (errno == EWOULDBLOCK || errno == EINTR) return -1; syslog(LOG_ERR, "read: %m"); die(1); } return len; }
now, this looks totally sane... question is (right as you wrote): Why does select return a socket which returns EWOULDBLOCK on read?
I'm not sure but I can imagine two cases: a) there is no data and select is broken b) there is data and read doesn't want to read it
cheers simon
-- /"\ \ / \ ASCII Ribbon Campaign / \ Against HTML Mail and News
Attachment:
PGP.sig
Description: This is a digitally signed message part