Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759414Ab2FEITI (ORCPT ); Tue, 5 Jun 2012 04:19:08 -0400 Received: from smtp.nokia.com ([147.243.1.48]:32490 "EHLO mgw-sa02.nokia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756291Ab2FEITF convert rfc822-to-8bit (ORCPT ); Tue, 5 Jun 2012 04:19:05 -0400 From: To: , CC: , , , , , , , Subject: RE: [PATCH 0/5] Some vmevent fixes... Thread-Topic: [PATCH 0/5] Some vmevent fixes... Thread-Index: AQHNP/FOitsSrN1KnkOrXYpeZEkA+pboy3gAgADvzACAADBdAIAACvEAgAAV0wCAATLWgIAAAdUAgAAAbICAACQwcA== Date: Tue, 5 Jun 2012 08:16:12 +0000 Message-ID: <84FF21A720B0874AA94B46D76DB98269045EBBD8@008-AM1MPN1-003.mgdnok.nokia.com> References: <20120601122118.GA6128@lizard> <4FCC7592.9030403@kernel.org> <20120604113811.GA4291@lizard> <20120604121722.GA2768@barrios> <20120604133527.GA13650@lizard> <4FCDBC8E.1000705@kernel.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.162.64.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2012 08:16:13.0249 (UTC) FILETIME=[78A9C310:01CD42F3] X-Nokia-AV: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1235 Lines: 22 > -----Original Message----- > From: penberg@gmail.com [mailto:penberg@gmail.com] On Behalf Of ext > Pekka Enberg > Sent: 05 June, 2012 11:02 > To: Minchan Kim ... > > Next concern is that periodic timer of implementation. > > I think it would add direct hook in vmscan.c rather than peeking raw > > vmstat periodically by timer so we can control more fine-grained way > without unnecessary overhead. > > If the hooks are clean and it doesn't hurt the !CONFIG_VMEVENT case, I'm > completely OK with that. On the previous iteration hooking vm was pointed as very bad idea, so in my version I installed shrinker to handle cases when we have memory pressure. Using deferred timer with adequate timeout (0.250 ms or larger) fully suitable for userspace and produce adequate overhead -> by nature such API should not be 100% accurate, anyhow applications cannot handle situation as good as kernel can provide, 0.5MB space accuracy, 100ms is maximum user-space require for 64-1024MB devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/