Hello
I looked at the SVG graphs and it appears that the formula used wasn't
T_load+T_decompress, but was just T_decompress.
Without considering the time it takes to load the compressed data from
a storage device, the SVG graphs are only half-done and might be
deceiving.
There are 3 kinds of typ
On Sun, Jul 5, 2020 at 1:58 PM Greg KH wrote:
>
> On Sun, Jul 05, 2020 at 06:09:03AM +0200, Jan Ziak wrote:
> > On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox wrote:
> > >
> > > On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> > > > On
On Sun, Jul 5, 2020 at 8:32 AM Andreas Dilger wrote:
>
> On Jul 4, 2020, at 8:46 PM, Jan Ziak <0xe2.0x9a.0...@gmail.com> wrote:
> >
> > On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
> >>
> >> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak
On Sun, Jul 5, 2020 at 5:27 AM Matthew Wilcox wrote:
>
> On Sun, Jul 05, 2020 at 05:18:58AM +0200, Jan Ziak wrote:
> > On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote:
> > >
> > > You should probably take a look at io_uring. That has the level of
> &g
On Sun, Jul 5, 2020 at 5:12 AM Matthew Wilcox wrote:
>
> You should probably take a look at io_uring. That has the level of
> complexity of this proposal and supports open/read/close along with many
> other opcodes.
Then glibc can implement readfile using io_uring and there is no need
for a new
On Sun, Jul 5, 2020 at 4:16 AM Matthew Wilcox wrote:
>
> On Sun, Jul 05, 2020 at 04:06:22AM +0200, Jan Ziak wrote:
> > Hello
> >
> > At first, I thought that the proposed system call is capable of
> > reading *multiple* small files using a single system call - whi
Hello
At first, I thought that the proposed system call is capable of
reading *multiple* small files using a single system call - which
would help increase HDD/SSD queue utilization and increase IOPS (I/O
operations per second) - but that isn't the case and the proposed
system call can read just a
7 matches
Mail list logo
