From owner-freebsd-hackers@freebsd.org Fri Dec 28 08:45:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 481BC14312B0 for ; Fri, 28 Dec 2018 08:45:25 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09631806F1; Fri, 28 Dec 2018 08:45:23 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 3C11AAB58C; Fri, 28 Dec 2018 09:45:20 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H99XVaxWhqD7; Fri, 28 Dec 2018 09:45:19 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 269DEAB586; Fri, 28 Dec 2018 09:45:19 +0100 (CET) Subject: Re: Using kqueue with aio_read/write To: Alan Somers Cc: FreeBSD Hackers References: <8753521a-4555-ec2a-5efc-dee2660b4d9b@digiware.nl> From: Willem Jan Withagen Message-ID: <70a07f49-cddd-5d13-ec94-88e06b4c3fc0@digiware.nl> Date: Fri, 28 Dec 2018 09:45:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 08:45:25 -0000 On 28-12-2018 02:47, Alan Somers wrote: > On Thu, Dec 27, 2018 at 6:15 PM Willem Jan Withagen wrote: >> >> Hi, >> >> Im trying to understand why I cannot get so code to work. >> This is the smallest extract I can make to show my problem. >> >> I would expect the kevent() call to return every timeo tick. >> Even if I tell it NOT to time-out I get these spurts of errors >> >> Since there is nothing to trigger the AIO-event, I would expect kqueue >> to hold indefinitly. >> >> But it does not generate anything other than errors >> And instead it repeatedly complains that there is a permission error: >> get_events_kevent: EV_Error(1) kevent(): Operation not permitted >> >> But I'm not getting where that would the case... >> >> Surely a pilot error, but I do overlook it al the time. >> So suggestions are welcome. >> >> Thanx, >> --WjW >> >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> #include >> >> #define BUFFER_SIZE 512 >> #define MAX_EVENTS 32 >> >> #define FILENAME "/tmp/aio_test" >> char filename[256]; >> int fd; >> int done = 0; >> >> void get_events_kevent(int fd, int kq) >> { >> printf("get_events function fd = %d, kq = %d\n", fd, kq); >> int i = 0, errcnt = 0, err, ret, reterr, rev; >> int search = 1; >> >> int timeout_ms = 10; >> struct timespec timeo = { >> timeout_ms / 1000, >> (timeout_ms % 1000) * 1000 * 1000 >> }; >> struct kevent filter[16]; >> struct kevent changed[16]; >> >> EV_SET(&filter[0], fd, EVFILT_AIO, >> EV_ADD, >> 0, 0, 0 ); > > > This is the first problem. There's no need to explicitly set > EVFILT_AIO on the kqueue. It gets set by the aio_read(2) or similar > syscall. And this invocation wouldn't be correct anyway, because for > AIO the ident field refers to the address of the struct aiocb, not the > file descriptor. If the only events you care about are AIO, then you > can pass NULL as the filter argument to kevent. I suspect this is the > cause of your problem. The kernel probably thinks you're trying to > register for an aiocb that's outside of your address space or > something like that. Hi Alan, That at least helps against getting EPERM. And I get a nice stream of timeouts hitting kevent. It sort of makes sense when you write it like this, but then this is not clear at all from the man pages (for me that is) But it seems sort of weird to "not filter" to get AIO events. >> while (!done) { >> printf("+"); >> rev = kevent(kq, filter, 1, changed, 16, 0); //&timeo); >> if (rev < 0) { >> perror("kevent error"); >> } else if (rev == 0) { >> printf("T"); >> } else { >> printf("rev(%d)\n", rev); >> if (changed[0].flags == EV_ERROR) { >> errno = changed[0].data; >> printf( "%s: EV_Error(%d) kevent(): %s\n", __func__, errno, >> strerror(errno)); >> memset(&changed[0], 0, sizeof(struct kevent)); >> } else { >> err = aio_error((struct aiocb*)changed[0].udata); > > > No need to call aio_error(2) after kevent(2) returns. You can go > straight to aio_return. aio_error shouldn't hurt, but it isn't > necessary. This is a sort of leftover from earlier trials where I was using a "home made" Poll iterating over the aiocb blocks. Thanx for the help, now I can go on trying getting this into Ceph. Perhaps I'll try an clean this up, and post a working example somewhere online. --WjW > > >> ret = aio_return((struct aiocb*)changed[0].udata); >> if (ret < 0 ) >> reterr = errno; >> if (err != 0) { >> printf( "%s: slot: %d, Error(%d) at aio_error(): >> %s\n", __func__, i, err, strerror (err)); >> errcnt++; >> if (errcnt > 50) { >> exit(3); >> } >> } >> } >> } >> } >> } >> >> int main() >> { >> (void) strcpy(filename, FILENAME); >> unlink(filename); >> fd = open(filename, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR); >> if (fd == -1) { >> printf( "%s: Error at open(): %s\n", __func__, strerror(errno)); >> exit(1); >> } >> >> int kq = kqueue(); >> if (fd == -1) { >> printf( "%s: Error at kqueue(): %s\n", __func__, strerror(errno)); >> exit(1); >> } >> >> get_events_kevent( fd, kq); >> >> close(kq); >> close(fd); >> return 0; >> } >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"