Date: Fri, 22 Jan 2016 19:47:11 +0800 From: Marcelo Araujo <araujobsdport@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r294543 - head/usr.sbin/ypldap Message-ID: <CAOfEmZjhxfvOS0Tzib=H8WRmzEN756frfUnT=CgkHufGf9OYAg@mail.gmail.com> In-Reply-To: <20160122222751.S1946@besplex.bde.org> References: <201601220302.u0M32dW2089530@repo.freebsd.org> <20160122173028.H966@besplex.bde.org> <CAOfEmZhZ=wU5Y4BqdvqhbyVKwSXZT-Gjw2Xcpby8xpMNGmWEog@mail.gmail.com> <20160122222751.S1946@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2016-01-22 19:37 GMT+08:00 Bruce Evans <brde@optusnet.com.au>: > On Fri, 22 Jan 2016, Marcelo Araujo wrote: > > 2016-01-22 15:57 GMT+08:00 Bruce Evans <brde@optusnet.com.au>: >> >>> ... >>> Unfortunately, getdtablesize() is still needed for arrays as used in yp*, >>> and for anything using select(). If getdtablesize() is large then the >>> arrays should be sparse or large fd's should not be actually used. >>> closefrom() should probably be used early to kill unknown fd's to make >>> space for private fd's. After that, getdtablesize() becomes almost >>> useless. You just allocate a table large enough for the fd's that >>> you allocate, and don't allocate fd's sparsely. >>> ... >>> >> >> I noticed that getdtablesize(2) specifically for ypldap(8) case is a bit >> slower than FD_SETSIZE, mostly because of the size of max_fd. >> > > freefall actually takes only 0.11 seconds to close 706977 mostly-non-open > fd's. But if you watch this using ktrace (with ktrace.out on nfs) it takes > 2.79 seconds for 1000 fd's or 33 minutes. ktrace on nfs is unusably slow. > I will check the yp(8) code to see how complex would be to get those getdtablesize(2) removed from there. > > However, as ypldap(8) was imported from OpenBSD seemed good to keep it as >> much as synced with OpenBSD implementation. Although I'm not sure if >> FreeBSD and OpenBSD shares the same getdtablesize(2) implementation. >> > > How did it diverge in the first place? > Mostly I fixed a bug, made a small benchmark and noticed that "not using getdtablesize(2)" would be fast, also for ypldap(8) I really don't see any case to have more than 1024 FD allocated, but in other hands, keep the code synced as closes as possible will make easy for future sync with OpenBSD. That was the main reason why I bring back getdtablesize(2). > > getdtablesize(2)'s implementation can't be much different, but its value > should be. Allowing 706977 fd's for a single thread should be considered > a security hole (just a denial of service one). The good part of getdtablesize(2) is the tunable part, however for ypldap(8), I really don't need that. The change was mostly to don't diverge too much from OpenBSD. > > > Not an excuse for sure, but I agree with you!!! >> > > Bruce > Best, -- -- Marcelo Araujo (__)araujo@FreeBSD.org \\\'',)http://www.FreeBSD.org <http://www.freebsd.org/>; \/ \ ^ Power To Server. .\. /_)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfEmZjhxfvOS0Tzib=H8WRmzEN756frfUnT=CgkHufGf9OYAg>