On Mon, Aug 05, 2013 at 09:20:13AM +0200, Michal Hocko wrote:
> On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> > On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> > > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> > >> >>> You missed the "!". I'm proposing that setting the new bit 2 w
On Sun 04-08-13 21:13:44, KOSAKI Motohiro wrote:
> On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> > On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> >> >>> You missed the "!". I'm proposing that setting the new bit 2 will
> >> >>> permit people to prevent the new printk if it is causing
On Sun, Aug 4, 2013 at 4:07 AM, Michal Hocko wrote:
> On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
>> >>> You missed the "!". I'm proposing that setting the new bit 2 will
>> >>> permit people to prevent the new printk if it is causing them problems.
>> >>
>> >> No I don't. I'm sure almost al
On Sat 03-08-13 16:16:58, KOSAKI Motohiro wrote:
> >>> You missed the "!". I'm proposing that setting the new bit 2 will
> >>> permit people to prevent the new printk if it is causing them problems.
> >>
> >> No I don't. I'm sure almost all abuse users think our usage is correct.
> >> Then,
> >>
>>> You missed the "!". I'm proposing that setting the new bit 2 will
>>> permit people to prevent the new printk if it is causing them problems.
>>
>> No I don't. I'm sure almost all abuse users think our usage is correct. Then,
>> I can imagine all crazy applications start to use this flag event
On 08/02/2013 09:04 AM, Rob Landley wrote:
> I'd be surprised if anybody who does this sees the printk and thinks
> "hey, I'll dig into the VM's balancing logic and come up to speed on the
> tradeoffs sufficient to contribute to kernel development" because of
> something in dmesg. Anybody actually
On 07/31/2013 10:17:08 PM, Andrew Morton wrote:
On Wed, 31 Jul 2013 23:11:50 -0400 KOSAKI Motohiro
wrote:
> >> --- a/fs/drop_caches.c
> >> +++ b/fs/drop_caches.c
> >> @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table
*table, int write,
> >> if (ret)
> >> return ret;
>
On Thu 01-08-13 21:39:48, KOSAKI Motohiro wrote:
> On Wed, Jul 31, 2013 at 11:17 PM, Andrew Morton
> wrote:
> > On Wed, 31 Jul 2013 23:11:50 -0400 KOSAKI Motohiro
> > wrote:
> >
> >> >> --- a/fs/drop_caches.c
> >> >> +++ b/fs/drop_caches.c
> >> >> @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler
On Wed, Jul 31, 2013 at 11:17 PM, Andrew Morton
wrote:
> On Wed, 31 Jul 2013 23:11:50 -0400 KOSAKI Motohiro
> wrote:
>
>> >> --- a/fs/drop_caches.c
>> >> +++ b/fs/drop_caches.c
>> >> @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *table, int
>> >> write,
>> >>if (ret)
>> >>
On Wed, 31 Jul 2013 23:11:50 -0400 KOSAKI Motohiro
wrote:
> >> --- a/fs/drop_caches.c
> >> +++ b/fs/drop_caches.c
> >> @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *table, int
> >> write,
> >>if (ret)
> >>return ret;
> >>if (write) {
> >> + printk(KERN
>> --- a/fs/drop_caches.c
>> +++ b/fs/drop_caches.c
>> @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *table, int write,
>> if (ret)
>> return ret;
>> if (write) {
>> +printk(KERN_INFO "%s (%d): dropped kernel caches: %d\n",
>> + curr
On Tue, 30 Jul 2013 07:47:12 -0700 Dave Hansen wrote:
> On 07/30/2013 05:55 AM, Michal Hocko wrote:
> >> > If we add another flag in the future it can use bit 3?
> > What if we get crazy and need more of them?
>
> I really hate using bits for these kinds of interfaces. I'm forgetful
> and never
On Tue, Jul 30, 2013 at 07:47:12AM -0700, Dave Hansen wrote:
> On 07/30/2013 05:55 AM, Michal Hocko wrote:
> >> > If we add another flag in the future it can use bit 3?
> > What if we get crazy and need more of them?
>
> I really hate using bits for these kinds of interfaces. I'm forgetful
> and
On Tue 30-07-13 07:39:56, Andrew Morton wrote:
> On Tue, 30 Jul 2013 14:55:25 +0200 Michal Hocko wrote:
>
> > > > I am OK with that but can we use a top bit instead. Maybe we never have
> > > > other entities to drop in the future but it would be better to have a
> > > > room for them
> > > > j
On 07/30/2013 05:55 AM, Michal Hocko wrote:
>> > If we add another flag in the future it can use bit 3?
> What if we get crazy and need more of them?
I really hate using bits for these kinds of interfaces. I'm forgetful
and never remember which bit is which, and they're possible to run out of.
I
On Tue, 30 Jul 2013 14:55:25 +0200 Michal Hocko wrote:
> > > I am OK with that but can we use a top bit instead. Maybe we never have
> > > other entities to drop in the future but it would be better to have a
> > > room for them
> > > just in case.
> >
> > If we add another flag in the future
On Tue 30-07-13 01:25:44, Andrew Morton wrote:
> On Tue, 30 Jul 2013 09:45:31 +0200 Michal Hocko wrote:
>
> > On Mon 29-07-13 13:57:43, Andrew Morton wrote:
> > > On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
> > [...]
> > > > --- a/fs/drop_caches.c
> > > > +++ b/fs/drop_caches.c
> > >
On Tue, 30 Jul 2013 09:45:31 +0200 Michal Hocko wrote:
> On Mon 29-07-13 13:57:43, Andrew Morton wrote:
> > On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
> [...]
> > > --- a/fs/drop_caches.c
> > > +++ b/fs/drop_caches.c
> > > @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *t
On Mon 29-07-13 13:57:43, Andrew Morton wrote:
> On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
[...]
> > --- a/fs/drop_caches.c
> > +++ b/fs/drop_caches.c
> > @@ -59,6 +59,8 @@ int drop_caches_sysctl_handler(ctl_table *table, int
> > write,
> > if (ret)
> > return ret;
>
On Fri, 26 Jul 2013 14:44:29 +0200 Michal Hocko wrote:
> ...
>
> : There is plenty of anecdotal evidence and a load of blog posts
> : suggesting that using "drop_caches" periodically keeps your system
> : running in "tip top shape". Perhaps adding some kernel
> : documentation will increase the
On Fri, Jul 26, 2013 at 02:44:29PM +0200, Michal Hocko wrote:
> I would like to resurrect Dave's patch. It was originally posted here
> https://lkml.org/lkml/2010/9/16/250 and I have resurrected it here
> https://lkml.org/lkml/2012/10/12/175 for the first time. There didn't
> seem to be any strong
I would like to resurrect Dave's patch. It was originally posted here
https://lkml.org/lkml/2010/9/16/250 and I have resurrected it here
https://lkml.org/lkml/2012/10/12/175 for the first time. There didn't
seem to be any strong opposition but the patch has been dropped later
from the mm tree.
To
22 matches
Mail list logo
