On Fri 29-04-16 20:54:13, Aaron Lu wrote:
> On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> > On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > > All of them are order-2 and this was a known problem for "mm, oom:
> >
On Fri 29-04-16 20:54:13, Aaron Lu wrote:
> On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> > On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > > All of them are order-2 and this was a known problem for "mm, oom:
> >
On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > All of them are order-2 and this was a known problem for "mm, oom:
> > > rework oom detection" commit and later should
On Fri, Apr 29, 2016 at 11:29:36AM +0200, Michal Hocko wrote:
> On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> > On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > > All of them are order-2 and this was a known problem for "mm, oom:
> > > rework oom detection" commit and later should
On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > All of them are order-2 and this was a known problem for "mm, oom:
> > rework oom detection" commit and later should make it much more
> > resistant to failures for higher (!costly)
On Fri 29-04-16 16:59:37, Aaron Lu wrote:
> On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> > All of them are order-2 and this was a known problem for "mm, oom:
> > rework oom detection" commit and later should make it much more
> > resistant to failures for higher (!costly)
On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> All of them are order-2 and this was a known problem for "mm, oom:
> rework oom detection" commit and later should make it much more
> resistant to failures for higher (!costly) orders. So I would definitely
> encourage you to retest
On Thu, Apr 28, 2016 at 01:21:35PM +0200, Michal Hocko wrote:
> All of them are order-2 and this was a known problem for "mm, oom:
> rework oom detection" commit and later should make it much more
> resistant to failures for higher (!costly) orders. So I would definitely
> encourage you to retest
On Thu 28-04-16 17:45:23, Aaron Lu wrote:
> On 04/28/2016 04:57 PM, Michal Hocko wrote:
> > On Thu 28-04-16 13:17:08, Aaron Lu wrote:
[...]
> >> I have the same doubt too, but the results look really stable(only for
> >> commit 0da9597ac9c0, see below for more explanation).
> >
> > I cannot seem
On Thu 28-04-16 17:45:23, Aaron Lu wrote:
> On 04/28/2016 04:57 PM, Michal Hocko wrote:
> > On Thu 28-04-16 13:17:08, Aaron Lu wrote:
[...]
> >> I have the same doubt too, but the results look really stable(only for
> >> commit 0da9597ac9c0, see below for more explanation).
> >
> > I cannot seem
On Thu 28-04-16 13:17:08, Aaron Lu wrote:
> On Wed, Apr 27, 2016 at 11:17:19AM +0200, Michal Hocko wrote:
> > On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> > > Michal Hocko writes:
> > >
> > > > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> > > >> Michal Hocko
On Thu 28-04-16 13:17:08, Aaron Lu wrote:
> On Wed, Apr 27, 2016 at 11:17:19AM +0200, Michal Hocko wrote:
> > On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> > > Michal Hocko writes:
> > >
> > > > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> > > >> Michal Hocko writes:
> > > >>
> > > >> > On
On Wed, Apr 27, 2016 at 11:17:19AM +0200, Michal Hocko wrote:
> On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> > Michal Hocko writes:
> >
> > > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> > >> Michal Hocko writes:
> > >>
> > >> > On Wed 27-04-16
On Wed, Apr 27, 2016 at 11:17:19AM +0200, Michal Hocko wrote:
> On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> > Michal Hocko writes:
> >
> > > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> > >> Michal Hocko writes:
> > >>
> > >> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
> > >> >>
On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> Michal Hocko writes:
>
> > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> >> Michal Hocko writes:
> >>
> >> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
> >> >> FYI, we noticed
On Wed 27-04-16 16:44:31, Huang, Ying wrote:
> Michal Hocko writes:
>
> > On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> >> Michal Hocko writes:
> >>
> >> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
> >> >> FYI, we noticed vm-scalability.throughput -11.8% regression with the
> >> >>
Michal Hocko writes:
> On Wed 27-04-16 16:20:43, Huang, Ying wrote:
>> Michal Hocko writes:
>>
>> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
>> >> FYI, we noticed vm-scalability.throughput -11.8% regression with the
>> >> following commit:
>> >
Michal Hocko writes:
> On Wed 27-04-16 16:20:43, Huang, Ying wrote:
>> Michal Hocko writes:
>>
>> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
>> >> FYI, we noticed vm-scalability.throughput -11.8% regression with the
>> >> following commit:
>> >
>> > Could you be more specific what
On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> Michal Hocko writes:
>
> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
> >> FYI, we noticed vm-scalability.throughput -11.8% regression with the
> >> following commit:
> >
> > Could you be more specific what the test does
On Wed 27-04-16 16:20:43, Huang, Ying wrote:
> Michal Hocko writes:
>
> > On Wed 27-04-16 11:15:56, kernel test robot wrote:
> >> FYI, we noticed vm-scalability.throughput -11.8% regression with the
> >> following commit:
> >
> > Could you be more specific what the test does please?
>
> The
Michal Hocko writes:
> On Wed 27-04-16 11:15:56, kernel test robot wrote:
>> FYI, we noticed vm-scalability.throughput -11.8% regression with the
>> following commit:
>
> Could you be more specific what the test does please?
The sub-testcase of vm-scalability is swap-w-rand.
Michal Hocko writes:
> On Wed 27-04-16 11:15:56, kernel test robot wrote:
>> FYI, we noticed vm-scalability.throughput -11.8% regression with the
>> following commit:
>
> Could you be more specific what the test does please?
The sub-testcase of vm-scalability is swap-w-rand. An RAM emulated
22 matches
Mail list logo