Re: [Rpm-maint] [rpm-software-management/rpm] RFC: What approach to improving performance through threads or non-blocking I/O is acceptable in RPM? (#517)

2018-08-21 Thread Jeff Johnson
Closed #517. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/517#event-1800135940___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: What approach to improving performance through threads or non-blocking I/O is acceptable in RPM? (#517)

2018-08-17 Thread Jeff Johnson
I was referring to using fsync wrapped in an event loop (and on rotating media), and was referring to rpm, not system, performance. Avoiding blocking system calls by using non-blocking alternatives in an event loop is what nodejs does. Rpmbuild and rpm both do loops over package operations and

Re: [Rpm-maint] [rpm-software-management/rpm] RFC: What approach to improving performance through threads or non-blocking I/O is acceptable in RPM? (#517)

2018-08-17 Thread Florian Festi
Mixing rpmbuild and rpm installation in the introduction is kinda weird as both are very different things. The added fsync actually lowers the performance of rpm to leave more air to the rest of the system. So it is not a "performance tweak" either. Focussing on rpm installation/update here:

[Rpm-maint] [rpm-software-management/rpm] RFC: What approach to improving performance through threads or non-blocking I/O is acceptable in RPM? (#517)

2018-08-16 Thread Jeff Johnson
Recent issues -- the pending PR for speeding up rpm kernel builds and the addition of fsync come to mind -- lead me to ask up front: What approaches to speeding up rpm installs are deemed acceptable? The techniques (event loop and/or threads and/or coroutines etc etc) are very well known. But