Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757957AbYAZA4V (ORCPT ); Fri, 25 Jan 2008 19:56:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753048AbYAZA4G (ORCPT ); Fri, 25 Jan 2008 19:56:06 -0500 Received: from threatwall.zlynx.org ([199.45.143.218]:33127 "EHLO zlynx.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752484AbYAZA4E (ORCPT ); Fri, 25 Jan 2008 19:56:04 -0500 Subject: Re: [RFC] Parallelize IO for e2fsck From: Zan Lynx To: Andreas Dilger Cc: Theodore Tso , Adrian Bunk , Bodo Eggert <7eggert@gmx.de>, Alan Cox , Valdis.Kletnieks@vt.edu, David Chinner , Valerie Henson , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org, Ric Wheeler In-Reply-To: <20080125110942.GX18433@webber.adilger.int> References: <9Mo9w-7Ws-23@gated-at.bofh.it> <9OdWm-7uN-25@gated-at.bofh.it> <9Oi9A-5EJ-3@gated-at.bofh.it> <9OiMg-6IC-1@gated-at.bofh.it> <9OlqL-2xG-3@gated-at.bofh.it> <9Orda-3ub-45@gated-at.bofh.it> <20080124230809.GA29120@does.not.exist> <20080124234037.GJ15858@mit.edu> <1201220742.7557.10.camel@localhost> <20080125110942.GX18433@webber.adilger.int> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-8OvqBAtkr4HvXMMKWXpO" Date: Fri, 25 Jan 2008 17:55:12 -0700 Message-Id: <1201308912.7784.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 X-Envelope-From: zlynx@acm.org X-Spam-Id: 20080125/1JIZKC-0004KE-TT-linux-kernel@vger.kernel.org:zlynx@acm.org:199.45.143.218 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1832 Lines: 56 --=-8OvqBAtkr4HvXMMKWXpO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2008-01-25 at 04:09 -0700, Andreas Dilger wrote: > On Jan 24, 2008 17:25 -0700, Zan Lynx wrote: > > Have y'all been following the /dev/mem_notify patches? > > http://article.gmane.org/gmane.linux.kernel/628653 >=20 > Having the notification be via poll() is a very restrictive processing > model. Having the notification be via a signal means that any kind of > process (and not just those that are event loop driven) can register > a callback at some arbitrary point in the code and be notified. I > don't object to the poll() interface, but it would be good to have a > signal mechanism also. The commentary on the mem_notify threads claimed that the signal is easily provided by setting up the file handle for SIGIO. Yeah. Here it is...copied from email written by KOSAKI Motohiro: implement FASYNC capability to /dev/mem_notify. fd =3D open("/dev/mem_notify", O_RDONLY); fcntl(fd, F_SETOWN, getpid()); flags =3D fcntl(fd, F_GETFL); fcntl(fd, F_SETFL, flags|FASYNC); /* when low memory, receive SIGI= O */ --=20 Zan Lynx --=-8OvqBAtkr4HvXMMKWXpO Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQBHmoTwG8fHaOLTWwgRAqrUAJ9BqPjzdrwVehS2K6X740ZhufJk1wCfVj8U jWxnklmPauoBzUVuXxKKUjE= =YOk3 -----END PGP SIGNATURE----- --=-8OvqBAtkr4HvXMMKWXpO-- -- 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/