On (05/03/16 15:19), Minchan Kim wrote:
> > > > cat /sys/xxx/max_comp_stream returns num_online_cpus.
> > >
> > > One more thing,
> > >
> > > User:
> > > echo 4 > /sys/xxx/max_comp_stream"
> > > cat /sys/xxx/max_comp_streams
> > > 8
> >
> > sure, it can also be
> >
> > cat
On (05/03/16 15:19), Minchan Kim wrote:
> > > > cat /sys/xxx/max_comp_stream returns num_online_cpus.
> > >
> > > One more thing,
> > >
> > > User:
> > > echo 4 > /sys/xxx/max_comp_stream"
> > > cat /sys/xxx/max_comp_streams
> > > 8
> >
> > sure, it can also be
> >
> > cat
On (05/03/16 14:03), Minchan Kim wrote:
> > will io_stat node work for you?
>
> Firstly, I thought io_stat would be better. However, on second thought,
> I want to withdraw.
>
> I think io_stat should go away.
>
> failed_read
> failed_write
> invalid_io
>
> I think
On (05/03/16 14:03), Minchan Kim wrote:
> > will io_stat node work for you?
>
> Firstly, I thought io_stat would be better. However, on second thought,
> I want to withdraw.
>
> I think io_stat should go away.
>
> failed_read
> failed_write
> invalid_io
>
> I think
On Tue, May 03, 2016 at 02:57:15PM +0900, Sergey Senozhatsky wrote:
> On (05/03/16 14:40), Minchan Kim wrote:
> [..]
> > > At least, we need sanity check code, still?
> > > Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> > > cat /sys/xxx/max_comp_stream returns
On Tue, May 03, 2016 at 02:57:15PM +0900, Sergey Senozhatsky wrote:
> On (05/03/16 14:40), Minchan Kim wrote:
> [..]
> > > At least, we need sanity check code, still?
> > > Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> > > cat /sys/xxx/max_comp_stream returns
On (05/03/16 14:40), Minchan Kim wrote:
[..]
> > At least, we need sanity check code, still?
> > Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> > cat /sys/xxx/max_comp_stream returns num_online_cpus.
>
> One more thing,
>
> User:
> echo 4 > /sys/xxx/max_comp_stream"
>
On (05/03/16 14:40), Minchan Kim wrote:
[..]
> > At least, we need sanity check code, still?
> > Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> > cat /sys/xxx/max_comp_stream returns num_online_cpus.
>
> One more thing,
>
> User:
> echo 4 > /sys/xxx/max_comp_stream"
>
On (05/03/16 14:23), Minchan Kim wrote:
[..]
> > - zram->max_comp_streams = num;
> > - ret = len;
> > -out:
> > - up_write(>init_lock);
> > - return ret;
>
> At least, we need sanity check code, still?
> Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> cat
On (05/03/16 14:23), Minchan Kim wrote:
[..]
> > - zram->max_comp_streams = num;
> > - ret = len;
> > -out:
> > - up_write(>init_lock);
> > - return ret;
>
> At least, we need sanity check code, still?
> Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> cat
On Tue, May 03, 2016 at 02:23:24PM +0900, Minchan Kim wrote:
> On Mon, May 02, 2016 at 05:06:00PM +0900, Sergey Senozhatsky wrote:
> > On (05/02/16 16:25), Sergey Senozhatsky wrote:
> > [..]
> > > > Trivial:
> > > > We could remove max_strm now and change description.
> > >
> > > oh, yes.
> >
>
On Tue, May 03, 2016 at 02:23:24PM +0900, Minchan Kim wrote:
> On Mon, May 02, 2016 at 05:06:00PM +0900, Sergey Senozhatsky wrote:
> > On (05/02/16 16:25), Sergey Senozhatsky wrote:
> > [..]
> > > > Trivial:
> > > > We could remove max_strm now and change description.
> > >
> > > oh, yes.
> >
>
On Mon, May 02, 2016 at 05:06:00PM +0900, Sergey Senozhatsky wrote:
> On (05/02/16 16:25), Sergey Senozhatsky wrote:
> [..]
> > > Trivial:
> > > We could remove max_strm now and change description.
> >
> > oh, yes.
>
> how about something like this? remove max_comp_streams entirely, but
> leave
On Mon, May 02, 2016 at 05:06:00PM +0900, Sergey Senozhatsky wrote:
> On (05/02/16 16:25), Sergey Senozhatsky wrote:
> [..]
> > > Trivial:
> > > We could remove max_strm now and change description.
> >
> > oh, yes.
>
> how about something like this? remove max_comp_streams entirely, but
> leave
On Tue, May 03, 2016 at 01:29:02PM +0900, Sergey Senozhatsky wrote:
> On (05/03/16 11:30), Sergey Senozhatsky wrote:
> > > We are concerning about returing back to no per-cpu options but actually,
> > > I don't want. If duplicate compression is really problem(But It's really
> > > unlikely), we
On Tue, May 03, 2016 at 01:29:02PM +0900, Sergey Senozhatsky wrote:
> On (05/03/16 11:30), Sergey Senozhatsky wrote:
> > > We are concerning about returing back to no per-cpu options but actually,
> > > I don't want. If duplicate compression is really problem(But It's really
> > > unlikely), we
On (05/03/16 11:30), Sergey Senozhatsky wrote:
> > We are concerning about returing back to no per-cpu options but actually,
> > I don't want. If duplicate compression is really problem(But It's really
> > unlikely), we should try to solve the problem itself with different way
> > rather than
On (05/03/16 11:30), Sergey Senozhatsky wrote:
> > We are concerning about returing back to no per-cpu options but actually,
> > I don't want. If duplicate compression is really problem(But It's really
> > unlikely), we should try to solve the problem itself with different way
> > rather than
On (05/03/16 11:20), Minchan Kim wrote:
[..]
> We are concerning about returing back to no per-cpu options but actually,
> I don't want. If duplicate compression is really problem(But It's really
> unlikely), we should try to solve the problem itself with different way
> rather than roll-back to
On (05/03/16 11:20), Minchan Kim wrote:
[..]
> We are concerning about returing back to no per-cpu options but actually,
> I don't want. If duplicate compression is really problem(But It's really
> unlikely), we should try to solve the problem itself with different way
> rather than roll-back to
Hi Sergey!
On Tue, May 03, 2016 at 10:53:33AM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> On (05/03/16 10:40), Minchan Kim wrote:
> > >
> > > ...hm... inc ->failed_writes?
> [..]
> > Okay, let's add the knob to the existing sysfs(There is no different
> > between sysfs and debugfs
Hi Sergey!
On Tue, May 03, 2016 at 10:53:33AM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> On (05/03/16 10:40), Minchan Kim wrote:
> > >
> > > ...hm... inc ->failed_writes?
> [..]
> > Okay, let's add the knob to the existing sysfs(There is no different
> > between sysfs and debugfs
Hello Minchan,
On (05/03/16 10:40), Minchan Kim wrote:
> >
> > ...hm... inc ->failed_writes?
[..]
> Okay, let's add the knob to the existing sysfs(There is no different
> between sysfs and debugfs with point of userspace once they start to
> use it) because no need to add new code to avoid such
Hello Minchan,
On (05/03/16 10:40), Minchan Kim wrote:
> >
> > ...hm... inc ->failed_writes?
[..]
> Okay, let's add the knob to the existing sysfs(There is no different
> between sysfs and debugfs with point of userspace once they start to
> use it) because no need to add new code to avoid such
On Mon, May 02, 2016 at 06:21:57PM +0900, Sergey Senozhatsky wrote:
> On (05/02/16 17:28), Minchan Kim wrote:
> [..]
> > > aha... I misunderstood you. I thought you talked about the test results
> > > in particular, not about zram stats in general. hm, given that we don't
> > > close the door for
On Mon, May 02, 2016 at 06:21:57PM +0900, Sergey Senozhatsky wrote:
> On (05/02/16 17:28), Minchan Kim wrote:
> [..]
> > > aha... I misunderstood you. I thought you talked about the test results
> > > in particular, not about zram stats in general. hm, given that we don't
> > > close the door for
On (05/02/16 17:28), Minchan Kim wrote:
[..]
> > aha... I misunderstood you. I thought you talked about the test results
> > in particular, not about zram stats in general. hm, given that we don't
> > close the door for 'idle compression streams list' yet, and may revert
> > per-cpu streams, may
On (05/02/16 17:28), Minchan Kim wrote:
[..]
> > aha... I misunderstood you. I thought you talked about the test results
> > in particular, not about zram stats in general. hm, given that we don't
> > close the door for 'idle compression streams list' yet, and may revert
> > per-cpu streams, may
On Mon, May 02, 2016 at 04:25:08PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> On (05/02/16 15:23), Minchan Kim wrote:
> [..]
> > Thanks for the your great test.
> > Today, I tried making heavy memory pressure to make dobule compression
> > but it was not easy so I guess it's really
On Mon, May 02, 2016 at 04:25:08PM +0900, Sergey Senozhatsky wrote:
> Hello Minchan,
>
> On (05/02/16 15:23), Minchan Kim wrote:
> [..]
> > Thanks for the your great test.
> > Today, I tried making heavy memory pressure to make dobule compression
> > but it was not easy so I guess it's really
On (05/02/16 16:25), Sergey Senozhatsky wrote:
[..]
> > Trivial:
> > We could remove max_strm now and change description.
>
> oh, yes.
how about something like this? remove max_comp_streams entirely, but
leave the attr. if we keep zram->max_comp_streams and return its value
(set by user space)
On (05/02/16 16:25), Sergey Senozhatsky wrote:
[..]
> > Trivial:
> > We could remove max_strm now and change description.
>
> oh, yes.
how about something like this? remove max_comp_streams entirely, but
leave the attr. if we keep zram->max_comp_streams and return its value
(set by user space)
Hello Minchan,
On (05/02/16 15:23), Minchan Kim wrote:
[..]
> Thanks for the your great test.
> Today, I tried making heavy memory pressure to make dobule compression
> but it was not easy so I guess it's really hard to get in real practice
> I hope it doesn't make any regression. ;-)
:) it is
Hello Minchan,
On (05/02/16 15:23), Minchan Kim wrote:
[..]
> Thanks for the your great test.
> Today, I tried making heavy memory pressure to make dobule compression
> but it was not easy so I guess it's really hard to get in real practice
> I hope it doesn't make any regression. ;-)
:) it is
Hello Sergey,
Sorry for the late reply.
On Fri, Apr 29, 2016 at 01:17:10AM +0900, Sergey Senozhatsky wrote:
> Remove idle streams list and keep compression streams in per-cpu
> data. This removes two contented spin_lock()/spin_unlock() calls
> from write path and also prevent write OP from being
Hello Sergey,
Sorry for the late reply.
On Fri, Apr 29, 2016 at 01:17:10AM +0900, Sergey Senozhatsky wrote:
> Remove idle streams list and keep compression streams in per-cpu
> data. This removes two contented spin_lock()/spin_unlock() calls
> from write path and also prevent write OP from being
Remove idle streams list and keep compression streams in per-cpu
data. This removes two contented spin_lock()/spin_unlock() calls
from write path and also prevent write OP from being preempted
while holding the compression stream, which can cause slow downs.
For instance, let's assume that we
Remove idle streams list and keep compression streams in per-cpu
data. This removes two contented spin_lock()/spin_unlock() calls
from write path and also prevent write OP from being preempted
while holding the compression stream, which can cause slow downs.
For instance, let's assume that we
38 matches
Mail list logo
