> Someone who rejects emails wrote: Yeah, I could snark at you, too. But what's the point?
>>>> Problem is, starting X takes foreeeeever [under 10.1] >> I've now actually tried this for myself. >> I have a little more information. > Maybe, maybe not. Well, I have more information; it may not be _useful_... :-) > There are multiple applications that get started together, you have > only traced one of them. Very good point. I ran the whole command under ktrace -i, so I actually have ktrace data for each piece. I just checked the whole file, sorting by syscall times, and I find The `bad' run 546 546 xinit 0.753117553 RET __nanosleep50 0 544 549 X 0.296895070 RET poll 1 544 544 X 0.243910223 RET ioctl 0 544 549 X 0.109929501 RET poll 1 544 549 X 0.039969679 RET poll 1 544 544 X 0.039901056 CALL mmap(0,0xb000,PROT_READ|PROT_WRITE,0x1002<PRIVATE,ANONYMOUS,ALIGN=NONE>,0xffffffff,0,0) 544 549 X 0.036890455 RET poll 1 544 549 X 0.036889406 RET poll 1 544 544 X 0.029997974 RET poll 0 544 544 X 0.029997673 RET poll 0 544 544 X 0.029996880 RET poll 0 544 544 X 0.029996210 RET poll 0 544 549 X 0.026892913 RET poll 1 544 544 X 0.019547689 RET poll 0 544 544 X 0.016640645 GIO fd 14 read 32 bytes 544 544 X 0.016640250 GIO fd 14 read 32 bytes The `good' run 651 646 X 0.958075514 RET poll 1 652 652 xinit 0.749048999 RET __nanosleep50 0 651 651 X 0.244047365 RET ioctl 0 651 646 X 0.099944713 RET poll 1 651 646 X 0.048070375 RET poll 1 651 646 X 0.038074019 RET poll 1 651 651 X 0.029997741 RET poll 0 651 651 X 0.029996762 RET poll 0 651 651 X 0.029982132 RET poll 0 651 646 X 0.028070687 RET poll 1 651 651 X 0.021887630 RET poll 0 651 646 X 0.019969427 RET poll 1 651 646 X 0.018071397 RET poll 1 651 651 X 0.017139996 RET poll 0 651 651 X 0.014538550 RET poll 0 651 651 X 0.014473515 RET poll 0 So at least there's no single syscall that's responsible. > The only time that I see any delay in starting up X11 is if there is > a networking configuration problem that would cause a DNS lookup to > time out. That's one of my go-to explanations whenever anything network-capable is taking unusually long. But, in this case, the only difference is the kernel. So, while it's not entirely excluded, I do consider it a less plausible explanation in this case - the change has to follow from *something* kernel. > My guess is that the DNS lookup is to setup server access control. I don't entirely rule it out. But I do consider it unlikely, because, with the exact same userland (including X server and all clients), (a) 9.1 kernel, without -depth 8: fast (b) 9.1 kernel, with -depth 8: fast (c) 10.1 kernel, without -depth 8: fast (d) 10.1 kernel, with -depth 8: slow I'm having trouble constructing a plausible scenario in which -depth 8 leads to more trouble resolving something in the DNS. Maybe tech-x11 would be more useful? I've been using tech-kern because I saw this as a kernel change leading to a performance issue (in the above list of scenarios, changing from (b) to (d)), but it's starting to look to me more like an X server issue provoked by a kernel difference. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
