if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

My understanding= of GCM and GMAC was that GMAC was an authentication only variant of GCM, a= nd thus they were mutually exclusive. =A0But, it looks like the rest of the= function will never execute if GMAC isn't chosen as the mode of encryp= tion. =A0Does this mean that GCM uses GMAC as part of its standard encrypti= on process, or is the encryption for GCM only implemented somewhere else? = =A0Any help on this matter would be greatly appreciated.

Chris

--e89a8ff1bf64a8054e04c50836de-- From ftigeot at wolfpond.org Tue Jul 17 23:44:33 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 08:44:33 +0200 Subject: Quota on tmpfs Message-ID: On Tue, Jul 17, 2012 at 08:15:20AM -0400, Thor Lancelot Simon wrote: > > In the case of the sparse file, the user has explicitly taken actions > that -- on normal Unix systems and filesystems -- reduce the space > required to store the file. If I open a file and lseek() 1TB off > the end, I have a reasonable expectation to be charged for zero bytes > of storage, or perhaps the size of the inode -- not 1,000,000,000,000 > bytes of storage. The DragonFly VFS quota project was originally an existing Google Summer of Code proposal from 2010. I clearly remember some discussions about sparse files, and a preference beeing made about counting the seek size and not the number of actual blocks used. > However, it is not the case AFAICT that opening a file and seeking > 1TB off the end causes 1TB of allocation in HAMMER. Nor would I expect > the HAMMER maintainers to think such a behavior was desirable; as far > as I can tell they have more sense than that. HAMMER behaves in the same way as UFS, nothing changes here. > > Having a quota system based on visible file sizes gives at least consistent > > results with what a regular user sees when listing files or using du(1). > > You can say that because you avoid mentioning stat(2) or stat(1) or > (at least, not explicitly) ls(1), all of which do actually expose the > difference between the user's requested file length (st_size) and the > block allocations performed on behalf of the user (st_blocks * st_blksize). > > The problem is that you're mixing up apples and oranges: what the filesystem > (HAMMER) or storage device (deduplication) do behind the user's back which > may reduce or increase actual block usage on the underlying storage device > are fundamentally different from what the user expressly requests the > system do to manage block allocation (intentionally creating holes in files). > > Creating an inconsistency between what stat(2) reports and what is charged > against the user's quota really seems like a very bad idea. I understand > that you are trying to simplify away what looks to you like annoying > complexity, but consider the famous Einstein quote: "as simple as possible, > but no simpler". You've gone too simple: your scheme breaks user and > application expectations with regard to behavior the user/application > expressly requested from the kernel. Not a good thing. > > Existing applications reasonably expect that regardless of how much > disk space is available, they can lseek off the end of an existing > file and not get back an error. In fact, EDQUOT is not among the > documented error values for lseek(2) so applications will not > handle it (for the record, lseek also cannot return EFBIG nor ENOSPC). > So you can be pretty sure you will break a good number of existing > Unix applications, likely in data-corrupting ways! As far as I remember, potential application breakages concerns didn't come up when the decision was made to not specially handle sparse files. I may have to it if the first implementation really causes problems in practice. > Again, I am very curious whether you really have consensus from the > other Dragonfly developers in favor of this choice. There was no consensus, but no strong opposition either. Adding kernel@ to the discussion. -- Francois Tigeot From ftigeot at wolfpond.org Tue Jul 17 23:53:24 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 08:53:24 +0200 Subject: Quota on tmpfs Message-ID: On Tue, Jul 17, 2012 at 08:29:10PM +0100, David Laight wrote: > On Tue, Jul 17, 2012 at 01:51:17PM +0200, Francois Tigeot wrote: > > > > Having a quota system based on visible file sizes gives at least consistent > > results with what a regular user sees when listing files or using du(1). > > Ignoring fs metadata is unlikely to be a problem, it is only really > significant for sparse files (and maybe very small ones). > > But you do need to use the 'sparse' size for sparse files. > Many moons ago someone change unixware so that 'ls -s' reported a > value based on the file size - not the number of block used. > Really wasn't a good change at all. > NFI if it got reverted. I'd like to know more about this issue. Are there public records somewhere ? -- Francois Tigeot From ftigeot at wolfpond.org Wed Jul 18 00:18:49 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 09:18:49 +0200 Subject: Quota on tmpfs Message-ID: <846b29a979561b11908474829c7349f5@NO-ID-FOUND.mhonarc.org> On Tue, Jul 17, 2012 at 09:26:44PM -0400, Matthew Mondor wrote: > On Tue, 17 Jul 2012 20:54:28 +0000 (UTC) > mlelstv at serpens.de (Michael van Elst) wrote: > > > I would also guess that sparse files are very rarely used. But for > > disk usage purposes you want to consider real disk usage including > > overhead because the quotas are mostly used to partition the available > > space. That doesn't work if your quotas allow you to write a few > > thousand files of 1 byte length that account together as a single > > single block when they really occupy a few thousand blocks. > > A scenario in which they're frequently used is block-based file system > transfer protocols (especially distributed ones where blocks may > download in random order, including bittorrent), also by download > managers that support "download optimization" where multiple > connections will be made to transfer multiple file sections at a time > (i.e. the DownloadThemAll Firefox extension). > > Another common usage of sparse files is for live file system images. > The cost of creation (open/creat + trunk/lseek + newfs) is small > compared to writing a full image of zeros, then the blocks can be > lazily allocated and written when needed. And this last usage is one good reason to only count seek sizes and not holes in files. Disk quotas can fill up suddenly when data is written to what appears to be a perfectly sized device. The potential for disruption of virtualized systems is very high in this situation and it was deemed best to count the full file size at creation time and avoid bad surprises. -- Francois Tigeot From ahornung at gmail.com Wed Jul 18 03:33:34 2012 From: ahornung at gmail.com (Alex Hornung) Date: Wed, 18 Jul 2012 11:33:34 +0100 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/07/12 09:11, Markus Pfeiffer wrote: > Question is now: Should we have similar functionality (i.e. per > open filedescriptor "private" data) and if yes how to best > implement that. I know that AlexH had made some suggestion but I > cannot find it in the IRC logs and it would probably be more > efficient doing this by mail. My original suggestion, which is straight forward to implement, is to just store the fp in each of the devfs_fo_* operations somewhere (e.g. curthread like FreeBSD, although that isn't all that nice), and then clean it up on devfs_fo_close. Having that, you can easily implement the rest to set up some list or tree or whatever inside a cdev that is also passed to the function. the search key would then be the fp that you stored somewhere whilst in devfs_fo_*. HTH, Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBpD+AAoJEInr8DonK72KMuEIAIa2/rGQeMivoWj19iFQkbWH 3Qi/bw6HeQ8392B5lG7P5c1eY9zxJCZZnME4vrUGX+IaWepXlZyHfsosFQ6KyiTu K4GIm5HSLBATS9vAgQotZ7yHyExy+m54AZ6C4mXkwK4lU8/5+Gi4wV6D/8lg4Fco pxKjDL9IOXUUQmXvQ6bC5xu8uX8JKuobO3N6LSjJpHwQkHb89fTi2ELh18aOxV6G uh1BBu4AQFtlDC9wGb/5599wAAGTzSDdvzSBkADs4ckhh204xBlNMEQgBT+f1QCf BuEtIgifU10nqMVd9fPbNMzEfC0mCq8JVOsgBrOGqjyZG+1upLNM8QhuokoYO8g= =C91L -----END PGP SIGNATURE----- From ftigeot at wolfpond.org Wed Jul 18 04:53:17 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 13:53:17 +0200 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: On Tue, Jul 17, 2012 at 08:11:13AM +0000, Markus Pfeiffer wrote: > > while porting drivers from FreeBSD some of us have stumbled over the functions > devfs_get_cdevpriv and devfs_set_cdevpriv, which store some > per-open-filedescriptor information for some devices. > > I looked into the FreeBSD code and the implementation seems weird to me since > they store the filedescriptor on syscall in their thread struct and the functions > rely on that hidden state. > > Question is now: Should we have similar functionality (i.e. per open > filedescriptor "private" data) and if yes how to best implement that. Have a look at our existing drm infrastructure; there is already some code doing this (a direct replacement of the FreeBSD version). -- Francois Tigeot From tls at panix.com Wed Jul 18 05:10:54 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 08:10:54 -0400 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 08:44:33AM +0200, Francois Tigeot wrote: > > As far as I remember, potential application breakages concerns didn't come > up when the decision was made to not specially handle sparse files. > > I may have to it if the first implementation really causes problems in > practice. > > > Again, I am very curious whether you really have consensus from the > > other Dragonfly developers in favor of this choice. > > There was no consensus, but no strong opposition either. > > Adding kernel@ to the discussion. The other important point that came up yesterday, I think - perhaps more important than mine - is that counting file length rather than allocated blocks allows behaviors that can evade the quota system and fill up the disk. As Michael pointed out, filesystems have a minimum allocation size. For simplicity, let's talk about a FFS filesystem with an 8K block and a 1K fragment. If I open a file and write one byte, under your scheme I am charged for only one byte; but I actually consume 1K of disk space. Do it 1,000 times, and I consume 1MB of space but am charged for only 1K. So both because you can count too much (and break applications that suddenly get impermissible errors from lseek) and count too little (and charge applications for a byte instead of a minimum allocation unit) this seems dubious indeed. Thor From tls at panix.com Wed Jul 18 09:00:25 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 12:00:25 -0400 Subject: Quota on tmpfs Message-ID: <377f84fb72ad1b1710b6aefa5c730faf@NO-ID-FOUND.mhonarc.org> On Wed, Jul 18, 2012 at 11:35:57AM -0400, Mouse wrote: > > So both because you can count too much (and break applications that > > suddenly get impermissible errors from lseek) > > Um, why would anything quota-related ever cause errors from lseek? Because he applies quotas to file length. The lseek is what will take you over quota, whether you ever write or not. Thor From tls at panix.com Wed Jul 18 09:27:05 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 12:27:05 -0400 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 12:11:10PM -0400, Mouse wrote: > >> Um, why would anything quota-related ever cause errors from lseek? > > Because he applies quotas to file length. The lseek is what will > > take you over quota, whether you ever write or not. > > At least in my experience, lseek never affects any file's size. lseek > such that the file pointer is left past EOF sets it up so a write will > extend the file (with a hole, if far enough past EOF and holes are > supported), but the lseek itself shouldn't do anything to file size. Of course you're right. So the error will come back from write() and applications _should_ handle EDQUOT from write, unless they're written on the assumption nothing but them is ever writing -- but that would not be a good assumption to ever make (I am reminded how C News used to suffer from this). Data corruption should be unlikely but the problem of confounding the application's (and user's) expectations in this case does remain. Thor From dholland-tech at netbsd.org Wed Jul 18 13:39:55 2012 From: dholland-tech at netbsd.org (David Holland) Date: Wed, 18 Jul 2012 20:39:55 +0000 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 09:18:49AM +0200, Francois Tigeot wrote: > > > I would also guess that sparse files are very rarely used. But for > > > disk usage purposes you want to consider real disk usage including > > > overhead because the quotas are mostly used to partition the available > > > space. That doesn't work if your quotas allow you to write a few > > > thousand files of 1 byte length that account together as a single > > > single block when they really occupy a few thousand blocks. > > > > A scenario in which they're frequently used is block-based file system > > transfer protocols (especially distributed ones where blocks may > > download in random order, including bittorrent), also by download > > managers that support "download optimization" where multiple > > connections will be made to transfer multiple file sections at a time > > (i.e. the DownloadThemAll Firefox extension). > > > > Another common usage of sparse files is for live file system images. > > The cost of creation (open/creat + trunk/lseek + newfs) is small > > compared to writing a full image of zeros, then the blocks can be > > lazily allocated and written when needed. > > And this last usage is one good reason to only count seek sizes and not > holes in files. Disk quotas can fill up suddenly when data is written to > what appears to be a perfectly sized device. > The potential for disruption of virtualized systems is very high in this > situation and it was deemed best to count the full file size at creation > time and avoid bad surprises. It seems like a better way to address that problem would be to provide a scheme to allocate all the blocks in the image files you're concerned about. -- David A. Holland dholland at netbsd.org From ahornung at gmail.com Thu Jul 19 01:14:07 2012 From: ahornung at gmail.com (Alex Hornung) Date: Thu, 19 Jul 2012 09:14:07 +0100 Subject: AES GCM/GMAC Message-ID: Hi, On 17/07/12 16:29, Chris Rogers wrote: > My understanding of GCM and GMAC was that GMAC was an authentication > only variant of GCM, and thus they were mutually exclusive. But, it > looks like the rest of the function will never execute if GMAC isn't > chosen as the mode of encryption. Does this mean that GCM uses GMAC as > part of its standard encryption process, or is the encryption for GCM > only implemented somewhere else? Any help on this matter would be > greatly appreciated. GMAC is just a special case of GCM where the plaintext has zero length, and the whole input is in the AAD. GCM encryption is implemented via transforms (xforms) in our opencrypto. it is effectively a special case of AES CTR, as the other bits that are distinct from CTR (the galois field arithmetic that ends up providing authentication) are implemented in our GMAC implementation. So yes, in other words our GCM uses AES CTR combined with GMAC underneath, resulting, effectively, in GCM. HTH, Alex From crogers122 at gmail.com Thu Jul 19 09:54:39 2012 From: crogers122 at gmail.com (Chris Rogers) Date: Thu, 19 Jul 2012 12:54:39 -0400 Subject: More with AES GCM/GMAC Message-ID: --e89a8ff243c1a17c3704c531a204 Content-Type: text/plain; charset=ISO-8859-1 This is in reference to Alex's reply here . So, let's use this scenario. I'm using an IPsec client that chooses AES GCM 16 as its mode of encryption for ESP. It creates a security association (SA) object, and sends that to the kernel via a socket. It is worthy to note that the authentication portion of this SA is null because it is assumed that GCM will inherently ensure integrity. When this SA reaches the kernel, and is processed through xform_esp.c, key.c, and when it finally reaches cryptosoft.c, there's only one session in the swcr_data struct; namely, the one for GCM. When we try to step through the switch statement, we correctly set the following since it sw->sw_alg is recognized as the CRYPTO_AES_GCM_16 case : swe = sw; crde = crd; exf = swe->sw_exf; ivlen = exf->blocksize; However, since there are no more sessions to jump into any of the CRYPTO_AES_*_GMAC cases, we fail to set any of these: swa = sw; crda = crd; axf = swa->sw_axf; if (swa->sw_ictx == 0) return (EINVAL); bcopy(swa->sw_ictx, &ctx, axf->ctxsize); blksz = axf->blocksize; which are needed by the subsequent if statement: if (crde == NULL || crda == NULL) return (EINVAL); Thus, we return from swcr_combined with an error value of 22 for Invalid Arguments. I'm assuming that the native IPsec client on Dragonfly somehow accounts for this, and will correctly initialize a second session to ensure that the GMAC portion is executed. Pfkeyv2.h doesn't have a SADB_X_AALG ID defined for GMAC, so it must only be used for encryption, and yet the GMACs are defined in auth_hash structs. So, my next question is, how is that session created? How do we get the GMAC case to trigger, and lend its portion of the encryption to GCM without specifying it explicitly as an authentication algorithm in the SA (because that creates a whole host of other problems a lot deeper in the kernel)? --e89a8ff243c1a17c3704c531a204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is in reference to Alex's reply here.

So, let= 9;s use this scenario.=A0 I'm using an IPsec client that chooses AES GC= M 16 as its mode of encryption for ESP.=A0 It creates a security associatio= n (SA) object, and sends that to the kernel via a socket.=A0 It is worthy t= o note that the authentication portion of this SA is null because it is ass= umed that GCM will inherently ensure integrity.=A0 When this SA reaches the= kernel, and is processed through xform_esp.c, key.c, and when it finally r= eaches cryptosoft.c, there's only one session in the swcr_data struct; = namely, the one for GCM.=A0 When we try to step through the switch statemen= t, we correctly set the following since it sw->sw_alg is recognized as t= he CRYPTO_AES_GCM_16 case :

swe =3D sw;
crde =3D crd;
exf =3D swe->sw_exf;
ivlen =3D ex= f->blocksize;

However, since there are no more sessions to jump i= nto any of the CRYPTO_AES_*_GMAC cases, we fail to set any of these:
swa =3D sw;
crda =3D crd;
axf =3D swa->sw_axf;
if (swa->sw_ictx =3D=3D 0)=A0=A0=A0 return (EINVAL);
bcopy(swa->sw_ictx, &ctx, axf->ct= xsize);
blksz =3D axf->blocksize;

which are needed by the subs= equent if statement:

if (crde =3D=3D NULL || crda =3D=3D NULL)
=A0=A0=A0 =A0=A0=A0 return= (EINVAL);

Thus, we return from swcr_combined with an error value of= 22 for Invalid Arguments.=A0

I'm assuming that the native IPse= c client on Dragonfly somehow accounts for this, and will correctly initial= ize a second session to ensure that the GMAC portion is executed. Pfkeyv2.h= doesn't have a SADB_X_AALG ID defined for GMAC, so it must only be use= d for encryption, and yet the GMACs are defined in auth_hash structs.=A0 So= , my next question is, how is that session created?=A0 How do we get the GM= AC case to trigger, and lend its portion of the encryption to GCM without s= pecifying it explicitly as an authentication algorithm in the SA (because t= hat creates a whole host of other problems a lot deeper in the kernel)? --e89a8ff243c1a17c3704c531a204-- From ahornung at gmail.com Thu Jul 19 15:07:08 2012 From: ahornung at gmail.com (Alex Hornung) Date: Thu, 19 Jul 2012 23:07:08 +0100 Subject: More with AES GCM/GMAC Message-ID: <774daf05893f162a4f2fd8ce43000afd@NO-ID-FOUND.mhonarc.org> On 19/07/12 17:54, Chris Rogers wrote: > I'm assuming that the native IPsec client on Dragonfly somehow accounts > for this, and will correctly initialize a second session to ensure that > the GMAC portion is executed. Pfkeyv2.h doesn't have a SADB_X_AALG ID > defined for GMAC, so it must only be used for encryption, and yet the > GMACs are defined in auth_hash structs. So, my next question is, how is > that session created? How do we get the GMAC case to trigger, and lend > its portion of the encryption to GCM without specifying it explicitly as > an authentication algorithm in the SA (because that creates a whole host > of other problems a lot deeper in the kernel)? Our IPsec implementation does not support AES GCM nor GMAC. To support it, we would indeed need something setting up an encryption algorithm as well as an authentication algorithm. See [1] for OpenBSD's implementation of some of the relevant bits. In general we do have a bit of a partially outdated mess with ipsec (we do have two implementations if I recall correctly, none of them well tested as far as I know). Take this last bit with a pinch of salt; I'm sure there are people who know more about the state of ipsec in DragonFly. HTH, Alex [1]: http://grok.x12.su/source/xref/openbsd/sys/netinet/ip_esp.c#164 PS: I'd appreciate it if you could reply to the thread instead of creating a new one with a *hyperlink* to an archived version of my mail. From mihai.carabas at gmail.com Mon Jul 23 00:22:19 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Mon, 23 Jul 2012 10:22:19 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <031b5b7639c1d961c451f03a8b421769@NO-ID-FOUND.mhonarc.org> --14dae9340d81358d3f04c57a1bb9 Content-Type: text/plain; charset=ISO-8859-1 Hello, Last week I finished implementing the new heuristic about cache hotness and obtained some new results in pgbench benchmark: ############enable smt######## kern.usched_bsd4.smt_enable: 0 -> 1 tps = 21651.867019 (including connections establishing) tps = 21647.787878 (including connections establishing) tps = 21588.095351 (including connections establishing) tps = 21607.754026 (including connections establishing) tps = 21625.132137 (including connections establishing) tps = 21765.227960 (including connections establishing) tps = 21646.292802 (including connections establishing) tps = 21513.203674 (including connections establishing) tps = 21666.282788 (including connections establishing) tps = 21656.393030 (including connections establishing) ############disable smt######## kern.usched_bsd4.smt_enable: 1 -> 0 tps = 20843.966453 (including connections establishing) tps = 20799.100980 (including connections establishing) tps = 20705.922558 (including connections establishing) tps = 20834.236784 (including connections establishing) tps = 20780.154608 (including connections establishing) tps = 20854.064166 (including connections establishing) tps = 20768.362228 (including connections establishing) tps = 20784.986692 (including connections establishing) tps = 20802.228183 (including connections establishing) tps = 20823.033787 (including connections establishing) You can see a difference of ~900-1000tps = 5%. Note: tps - transactions per second - more is better. For this test I ran 4 threads for the server and 4 clients. 4 of them are CPU-intensive and the other 4 are not. The tests were done on my Corei3. There is no patch commited yet. I will come with another e-mail when is ready. --14dae9340d81358d3f04c57a1bb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

--14dae9340d81358d3f04c57a1bb9-- From vishesh3y at gmail.com Mon Jul 23 02:20:28 2012 From: vishesh3y at gmail.com (Vishesh Yadav) Date: Mon, 23 Jul 2012 14:50:28 +0530 Subject: [GSoC] inotify and fs indexing service status Message-ID: <1e52bfe37f4bc4dbbe654b26f218d297@NO-ID-FOUND.mhonarc.org> Hello, This week I worked on finding and fixing few pending issues, and worked on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm hoping should be completed by today or tomorrow. Vishesh On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote: > Date: Mon, 16 Jul 2012 08:32:00 +0530 > From: Vishesh Yadav > To: kernel at crater.dragonflybsd.org > Subject: Re: [GSoC] inotify and fs indexing service status > > Hello, > > This week I completed work on IN_CREATE and did some testing on inotify > and found few bugs. IN_CREATE created some new bugs too on which I'm > currently working on. > > Vishesh > > On 07/08/2012 09:41 PM, Vishesh Yadav wrote: > > Hello, > > > > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These flags > > required some workaround as their behavior required a little more > > information than what is offered by kevent. There were few more problems > > with this including the merging of events in kqueue for which I'm trying to > > find a viable solution. > > > > Vishesh > > > > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav wrote: > > > >> Hello, > >> > >> I wasn't able to put much work on code last week. Did some work on man > >> pages. > >> > >> Vishesh > >> > >> > >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav wrote: > >> > >>> Hello, > >>> > >>> In fifth week I implement idr - integer management library using code of > >>> file descriptor allocators in kern_descrip.c. Worked to use the new library > >>> to be used with filedesc, however something or other didn't work out. Will > >>> be trying that again after looking at code more properly. Rest tested > >>> existing work done till now which seems to work quite fine. There are > >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED_FROM, which I'm > >>> being able to detect however have to synchronise them both using cookie > >>> argument. > >>> > >>> Vishesh > >>> > >>> > >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav wrote: > >>> > >>>> Hello, > >>>> > >>>> This week's status - > >>>> > >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS, > >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer > >>>> and UFS. > >>>> > >>>> * Implemented inotify_read() and have the most important masks working. > >>>> Hence now we have a working inotify system. > >>>> > >>>> Vishesh > >>>> > >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote: > >>>>> Hello, > >>>>> > >>>>> Not much new code this week. Improved and tested existing code, exposed > >>>>> watch/instance limits through sysctl and made the system respect the > >>>> limits. > >>>>> > >>>>> Rest studied kernel kqueue interface and its usage to be used in > >>>>> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE > >>>> and > >>>>> linux like idr integer management that can be used in fdalloc and watch > >>>>> descriptors. > >>>>> > >>>>> Regards, > >>>>> Vishesh > >>>>> > >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote: > >>>>>> Hello, > >>>>>> > >>>>>> This week I finished watch management functions. Now watches can be > >>>> added, > >>>>>> removed from into the inotify_instance. Hence inotify_add_watch, > >>>>>> inotify_rm_watch are now almost complete. Just have to check error > >>>> codes > >>>>>> that are being returned. I also implemented fo_close for inotify > >>>> fileops > >>>>>> which cleans up the instance well now. > >>>>>> > >>>>>> Regards, > >>>>>> Vishesh > >>>>>> > >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav > >>>> wrote: > >>>>>> > >>>>>>> Hello everyone, > >>>>>>> > >>>>>>> Current status for first week - > >>>>>>> > >>>>>>> - Repository and wiki setup at Github[1] > >>>>>>> - Made the basic skeleton for inotify interface - system calls, > >>>> helper > >>>>>>> functions, structures, headers and few basic stuff in there. > >>>>>>> - Currently working on management of watches (will be using separate > >>>>>>> file tables for watches). Once this is done, can write some working > >>>> code. > >>>>>>> > >>>>>>> In community bonding period, I setup my working environment, browse > >>>> and > >>>>>>> understood relevant kernel codebase and studied Linux early and > >>>> recent > >>>>>>> inotify implementation. > >>>>>>> > >>>>>>> Now that exams are almost over, I hope I can catch up some pace now. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Vishesh > >>>>>>> > >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/ > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > > > > -- -Vishesh From ivansichfreitas at gmail.com Tue Jul 24 20:37:32 2012 From: ivansichfreitas at gmail.com (Ivan Sichmann Freitas) Date: Wed, 25 Jul 2012 00:37:32 -0300 Subject: [GSoC] 32 bit api status Message-ID: --sl5MdczEF/OU2Miu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I still fixing issues with imported syscalls, I hope to finish this by the weekend. --=20 Ivan Sichmann Freitas GNU/Linux user #509059 --sl5MdczEF/OU2Miu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQD2n8AAoJEFM7yh3+vhFAeocP/2xjqhvMg2txy11iNTT8ZYmw s+ZhSrpZeEm2BV/WlHv/HnSj8kpOmxSk/DLDJ2pI4Dpd82T5BDucp3kjEQVvI3+R 8/BidTNkAadaTWMi+aS56hIbtcv+rf/Wcz8q4x2vJr3Gv0FqQt/UsnoCF4HOeeIX wGNZ/oTLL6TNeQra5qXFHpYBgKM+rktI7cHDpOWhHGNsy1D0PmNFnNgGnBtPNPxO 2wVLgmXNWEPeiC/nk7sYW5pkdPuTOcXNhTeK5eAW6sTgo807MxUzd2MLYqL4x6Q/ ssH7KDDuUSOvuVh4G2g1PuDpB5mubCyag2roguHFbyh0JgfCzDqbvCbQ2t4s5EKk 0ttFZ6PVrgLe2p4OUWLatI4khZtH8gdVnWqK82uufeYCs2oZSUIRYPzP7Sdm1NS2 HYmRr+r9xuzDAYHVt+6D1YfCETSCn8uwLBiI4+N8faFzHoyBz4dr3/Ti0JFGvlGU UCG7PijFxbOYcDrKxmTZbmgcRjVkCfOa6dJYYeJPTy5YoMsFqII/oBOjRce79guP aE5wFVT0jqvEq2/rRYCGeANRdjw8WYYYkBwyrm39sHiLKrkrFJL1MPn0WF0h3zjx 5zAMWD4WKIDABUG8VJq6rLRIAG7wjSrmhx4rDDBRY2zSo/2gUqyWNwz28xBC1y/g cnkUCvpF/38JWoJh/Guj =rCJp -----END PGP SIGNATURE----- --sl5MdczEF/OU2Miu-- From ahornung at gmail.com Tue Jul 24 23:32:35 2012 From: ahornung at gmail.com (Alex Hornung) Date: Wed, 25 Jul 2012 07:32:35 +0100 Subject: [GSoC] 32 bit api status Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Ivan, On 25/07/12 04:37, Ivan Sichmann Freitas wrote: > I still fixing issues with imported syscalls, I hope to finish this > by the weekend. could you please elaborate a bit more on your progress? What works? What doesn't? Which syscalls are still broken? Which ones have been ported? Do you have some spreadsheet or something like that with that information? What are your plans for the next 1 or 2 weeks? Cheers, Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQD5MDAAoJEInr8DonK72KIiQIAJpfjS5+tVZx3naOSngxRYBm /rZFwyT582xPr0nxWA3K/L8vQSFw+I569FGISHHlP6AZmPhtt38Qf5kj60/2fA4f 5DH1aVimzzsS+4P8xd+ShibocAN5e1Eg+hPEmVrwJzGOSc+F0Eaq0MMG0VruI5Rh BO21ZKYDmw8ezVtTeWiBrabZeTUEgubG2fxb3IxDga2cpkQ5NDkjbhvu8xOzLF8W oFNEGPrAEKOo+d0G5tBxXvKg0N4lAep28uo5r8YuemMWe9gPCV6Gf4iXC3znCn1a Hoj6tMGOUaG3ujLgyySNFUHSIKC6X13MxSOz9Hapk370PTBQbIpnYOAA0KE3ycQ= =b+Mw -----END PGP SIGNATURE----- From mihai.carabas at gmail.com Sat Jul 28 07:55:06 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sat, 28 Jul 2012 17:55:06 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <51b661e774c32a387cf68614d834f43f@NO-ID-FOUND.mhonarc.org> --f46d044787e5a950a204c5e503e5 Content-Type: text/plain; charset=ISO-8859-1 Hello, Sorry for not being so responsive on IRC on the end of this week (due to a personal problem). My smt heuristic is on my repo now. The code still looks very ugly. I also made some new benchmarks. Bad news: on the monster the performances are worst then the original scheduler. I didn't figure out why. I will try next week to do more testing. Another problem is if I modify the SMT heuristic, to make use of the HT topology (stick to the home cpu or its sibling because they share almost everything), there is no gain of perfomance (all the gain obtained by the SMT heuristic is lost). I haven't find the reason yet. Thanks ftigeot for giving me access to a dual-socket opteron (2 cpus). The results of testing: ############ enable smt ######## kern.usched_bsd4.smt_enable: 0 -> 1 tps = 11505.350032 (including connections establishing) tps = 12358.802902 (including connections establishing) tps = 10376.294593 (including connections establishing) tps = 10329.976654 (including connections establishing) tps = 11552.765499 (including connections establishing) ------------------------------------------------------ average = 11224 tps ############ disable smt ######## kern.usched_bsd4.smt_enable: 1 -> 0 tps = 8950.803833 (including connections establishing) tps = 9573.479233 (including connections establishing) tps = 8872.650887 (including connections establishing) tps = 10609.939778 (including connections establishing) tps = 10686.083868 (including connections establishing) ------------------------------------------------------- average = 9738 tps The command used was: pgbench -U pgsql -j 2 -c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including connections establishing" As you can see there is an important improvement. The results aren't so constant (because of the heuristic way of scheduling - at the end of the GSOC I will put online all my discussions with Alex and Matthew regarding the problems of scheduling). Another set of results on a core i7 (thanks Alex H): ############ enable smt ######## kern.usched_bsd4.smt_enable: 1 -> 1 tps = 36375.309531 (including connections establishing) tps = 35434.699607 (including connections establishing) tps = 35427.481274 (including connections establishing) tps = 35547.498123 (including connections establishing) tps = 35535.797652 (including connections establishing) tps = 33267.048739 (including connections establishing) tps = 35380.664997 (including connections establishing) tps = 33678.524173 (including connections establishing) tps = 33910.144898 (including connections establishing) tps = 30349.382087 (including connections establishing) tps = 31087.796990 (including connections establishing) tps = 32740.578796 (including connections establishing) tps = 29954.491639 (including connections establishing) tps = 31722.491643 (including connections establishing) tps = 30934.444499 (including connections establishing) tps = 31265.718351 (including connections establishing) ############ disable smt ######## kern.usched_bsd4.smt_enable: 1 -> 0 tps = 29049.152255 (including connections establishing) tps = 29634.008878 (including connections establishing) tps = 29271.273355 (including connections establishing) tps = 29001.174185 (including connections establishing) tps = 27541.959314 (including connections establishing) tps = 27643.877745 (including connections establishing) tps = 28197.062219 (including connections establishing) tps = 28535.076922 (including connections establishing) tps = 27269.922809 (including connections establishing) tps = 28948.932997 (including connections establishing) tps = 25764.057272 (including connections establishing) tps = 29550.489042 (including connections establishing) tps = 28679.242036 (including connections establishing) tps = 28552.329103 (including connections establishing) tps = 27933.380285 (including connections establishing) tps = 28727.222455 (including connections establishing) I also obtained some better results on my core i3 than last week, but the location of my machine is out of internet now and I don't have access to the results:(. --f46d044787e5a950a204c5e503e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Sorry for not being so responsive on IRC on the e= nd of this week (due to a personal problem).=A0My smt heuristic is on my re= po now. The code still looks very ugly. I also made some new benchmarks.

Bad news: on the monster the performances are worst the= n the original scheduler. I didn't figure out why. I will try next week= to do more testing.=A0Another problem is if I modify the SMT heuristic, to= make use of the HT topology (stick to the home cpu or its sibling because = they share almost everything), there is no gain of perfomance (all the gain= obtained by the SMT heuristic is lost). I haven't find the reason yet.=

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

As you can see= there is an important improvement. The results aren't so constant (bec= ause of the heuristic way of scheduling - at the end of the GSOC I will put= online all my discussions with Alex and Matthew regarding the problems of = scheduling).

Another set of results on a core i7 (thanks Alex H):

############ enable smt ####= ####
kern.usched_bsd4.smt_enable: 1 ->= 1
tps =3D 36375.309531 (including conn= ections establishing)
tps =3D 35434.699607 (including conn= ections establishing)
tps =3D 35427.481274 (including conn= ections establishing)
tps =3D 35547.498123 (including conn= ections establishing)
tps =3D 35535.797652 (including conn= ections establishing)
tps =3D 33267.048739 (including conn= ections establishing)
tps =3D 35380.664997 (including conn= ections establishing)
tps =3D 33678.524173 (including conn= ections establishing)
tps =3D 33910.144898 (including conn= ections establishing)
tps =3D 30349.382087 (including conn= ections establishing)
tps =3D 31087.796990 (including conn= ections establishing)
tps =3D 32740.578796 (including conn= ections establishing)
tps =3D 29954.491639 (including conn= ections establishing)
tps =3D 31722.491643 (including conn= ections establishing)
tps =3D 30934.444499 (including conn= ections establishing)
tps =3D 31265.718351 (including conn= ections establishing)

############ disable smt ########
kern.usched_bsd4.smt_enable: 1 ->= 0
tps =3D 29049.152255 (including conn= ections establishing)
tps =3D 29634.008878 (including conn= ections establishing)
tps =3D 29271.273355 (including conn= ections establishing)
tps =3D 29001.174185 (including conn= ections establishing)
tps =3D 27541.959314 (including conn= ections establishing)
tps =3D 27643.877745 (including conn= ections establishing)
tps =3D 28197.062219 (including conn= ections establishing)
tps =3D 28535.076922 (including conn= ections establishing)
tps =3D 27269.922809 (including conn= ections establishing)
tps =3D 28948.932997 (including conn= ections establishing)
tps =3D 25764.057272 (including conn= ections establishing)
tps =3D 29550.489042 (including conn= ections establishing)
tps =3D 28679.242036 (including conn= ections establishing)
tps =3D 28552.329103 (including conn= ections establishing)
tps =3D 27933.380285 (including conn= ections establishing)
tps =3D 28727.222455 (including conn= ections establishing)

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

--f46d044787e5a950a204c5e503e5-- From ftigeot at wolfpond.org Sat Jul 28 10:02:52 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Sat, 28 Jul 2012 19:02:52 +0200 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <6c065ba8fbaa86cbc115fe2d7b21d123@NO-ID-FOUND.mhonarc.org> On Sat, Jul 28, 2012 at 05:55:06PM +0300, Mihai Carabas wrote: > > Thanks ftigeot for giving me access to a dual-socket opteron (2 cpus). The > results of testing: > > ############ enable smt ######## > kern.usched_bsd4.smt_enable: 0 -> 1 > tps = 11505.350032 (including connections establishing) > tps = 12358.802902 (including connections establishing) > tps = 10376.294593 (including connections establishing) > tps = 10329.976654 (including connections establishing) > tps = 11552.765499 (including connections establishing) > ------------------------------------------------------ > average = 11224 tps > > ############ disable smt ######## > kern.usched_bsd4.smt_enable: 1 -> 0 > tps = 8950.803833 (including connections establishing) > tps = 9573.479233 (including connections establishing) > tps = 8872.650887 (including connections establishing) > tps = 10609.939778 (including connections establishing) > tps = 10686.083868 (including connections establishing) > ------------------------------------------------------- > average = 9738 tps > > The command used was: > pgbench -U pgsql -j 2 -c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | > grep "including connections establishing" > > As you can see there is an important improvement. The results aren't so > constant (because of the heuristic way of scheduling - at the end of the > GSOC I will put online all my discussions with Alex and Matthew regarding > the problems of scheduling). This machine is an old-school dual-Opteron 252 system and doesn't have any hyperthreading support at all. Its exact configuration is - 2 sockets - 1 core per socket (2.6 GHz, 1MB cache) - 2GB of RAM per socket - 1 thread per core Having an hyperthreading-aware scheduler shouldn't make any difference; what could explain the above performance differences ? -- Francois Tigeot From mihai.carabas at gmail.com Sat Jul 28 15:13:04 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sun, 29 Jul 2012 01:13:04 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <10cc9fef1230d0e0c1479d862e0892b4@NO-ID-FOUND.mhonarc.org> --14dae9340eb7f9def704c5eb2112 Content-Type: text/plain; charset=ISO-8859-1 Hi, > This machine is an old-school dual-Opteron 252 system and doesn't have > any hyperthreading support at all. > > Its exact configuration is > - 2 sockets > - 1 core per socket (2.6 GHz, 1MB cache) > - 2GB of RAM per socket > - 1 thread per core > > Having an hyperthreading-aware scheduler shouldn't make any difference; > what could explain the above performance differences ? > The heuristics I tested are about SMT (cache hotness heuristic - always tries to schedule on the last CPU that had run on. If we can't schedule on it and we are an cpu-bound process, we can wait for a tick to be ellected by our home CPU. If we aren't pulled after that, we are eligible and ready to be pulled on no matter what cpu). So, this heuristic doesn't have anything to do with HT (hyper threading). Mihai --14dae9340eb7f9def704c5eb2112 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

The heuristics I tested are about SMT (cache hotness heuristic - always tr= ies to schedule on the last CPU that had run on. If we can't schedule o= n it and we are an cpu-bound process, we can wait for a tick to be ellected= by our home CPU. If we aren't pulled after that, we are eligible and r= eady to be pulled on no matter what cpu). So, this heuristic doesn't ha= ve anything to do with HT (hyper threading).

Mihai

--14dae9340eb7f9def704c5eb2112-- From ahornung at gmail.com Sat Jul 28 15:22:54 2012 From: ahornung at gmail.com (Alex Hornung) Date: Sat, 28 Jul 2012 23:22:54 +0100 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: On 28/07/12 23:13, Mihai Carabas wrote: > Having an hyperthreading-aware scheduler shouldn't make any difference; > what could explain the above performance differences ? > > The heuristics I tested are about SMT (cache hotness heuristic - always > tries to schedule on the last CPU that had run on. If we can't schedule > on it and we are an cpu-bound process, we can wait for a tick to be > ellected by our home CPU. If we aren't pulled after that, we are > eligible and ready to be pulled on no matter what cpu). So, this > heuristic doesn't have anything to do with HT (hyper threading). The newer heuristics Mihai implemented are not specific to SMT/HT, but affect any multi-core machine, pretty much. It takes topology in general into account; that is: sockets, cores on the socket, and if available, threads in a core (SMT/HT). In other words, his scheduling changes affect any SMP machine. HTH, Alex From ftigeot at wolfpond.org Sat Jul 28 23:35:53 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Sun, 29 Jul 2012 08:35:53 +0200 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <83937ecf9a47975e34669b9458a58f52@NO-ID-FOUND.mhonarc.org> Hi, On Sun, Jul 29, 2012 at 01:13:04AM +0300, Mihai Carabas wrote: > > > This machine is an old-school dual-Opteron 252 system and doesn't have > > any hyperthreading support at all. > > Having an hyperthreading-aware scheduler shouldn't make any difference; > > what could explain the above performance differences ? > > > The heuristics I tested are about SMT (cache hotness heuristic - always > tries to schedule on the last CPU that had run on. If we can't schedule on > it and we are an cpu-bound process, we can wait for a tick to be ellected > by our home CPU. If we aren't pulled after that, we are eligible and ready > to be pulled on no matter what cpu). So, this heuristic doesn't have > anything to do with HT (hyper threading). Not wanting to nitpick, but for me SMT = Simultaneous Multi Threading, of which Hyper Threading is a particular implementation. Nothing to do with cache-hotness heuristics per se :) -- Francois Tigeot From ftigeot at wolfpond.org Sat Jul 28 23:39:31 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Sun, 29 Jul 2012 08:39:31 +0200 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <272d524e8b1afdc545c5fb9671e7376d@NO-ID-FOUND.mhonarc.org> On Sat, Jul 28, 2012 at 11:22:54PM +0100, Alex Hornung wrote: > > The newer heuristics Mihai implemented are not specific to SMT/HT, but > affect any multi-core machine, pretty much. It takes topology in general > into account; that is: sockets, cores on the socket, and if available, > threads in a core (SMT/HT). Which is uber-cool :-) -- Francois Tigeot From mihai.carabas at gmail.com Sun Jul 29 11:01:04 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sun, 29 Jul 2012 21:01:04 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <5bcdfa5d466928ba927d6e9b7f8f919e@NO-ID-FOUND.mhonarc.org> --14dae934116f99a22a04c5fbba48 Content-Type: text/plain; charset=ISO-8859-1 Hello, Here are some results from a AMD FX(tm)-8150 Eight-Core Processor(thanks profkmax): ############ enable smt ######## kern.usched_bsd4.smt_enable: 0 -> 1 tps = 32987.010952 (including connections establishing) tps = 33072.952733 (including connections establishing) tps = 32693.574568 (including connections establishing) tps = 33084.277648 (including connections establishing) tps = 33481.054536 (including connections establishing) tps = 33013.296931 (including connections establishing) tps = 32711.982849 (including connections establishing) tps = 32686.120901 (including connections establishing) tps = 32792.744933 (including connections establishing) tps = 33367.284545 (including connections establishing) ############ disable smt ######## kern.usched_bsd4.smt_enable: 1 -> 0 tps = 31364.873850 (including connections establishing) tps = 31340.974524 (including connections establishing) tps = 31648.286265 (including connections establishing) tps = 30913.788400 (including connections establishing) tps = 31338.052583 (including connections establishing) tps = 31360.521337 (including connections establishing) tps = 31545.915474 (including connections establishing) tps = 31489.008958 (including connections establishing) tps = 30657.108291 (including connections establishing) tps = 31294.472379 (including connections establishing) The difference is > 1500tps (5%). Here is an interesting CPU topology from a dual-socket XEON: hw.cpu_topology.tree: \-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu18 cpu19 cpu20 cpu21 cpu22 cpu23 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 cpu13 cpu15 cpu17 cpu19 cpu21 cpu23 | |-CORE ID 0: cpu1 cpu13 | | |-THREAD ID 0: cpu1 | | \-THREAD ID 1: cpu13 | |-CORE ID 1: cpu3 cpu15 | | |-THREAD ID 0: cpu3 | | \-THREAD ID 1: cpu15 | |-CORE ID 2: cpu5 cpu17 | | |-THREAD ID 0: cpu5 | | \-THREAD ID 1: cpu17 | |-CORE ID 8: cpu7 cpu19 | | |-THREAD ID 0: cpu7 | | \-THREAD ID 1: cpu19 | |-CORE ID 9: cpu9 cpu21 | | |-THREAD ID 0: cpu9 | | \-THREAD ID 1: cpu21 | \-CORE ID 10: cpu11 cpu23 | |-THREAD ID 0: cpu11 | \-THREAD ID 1: cpu23 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 cpu12 cpu14 cpu16 cpu18 cpu20 cpu22 |-CORE ID 0: cpu0 cpu12 | |-THREAD ID 0: cpu0 | \-THREAD ID 1: cpu12 |-CORE ID 1: cpu2 cpu14 | |-THREAD ID 0: cpu2 | \-THREAD ID 1: cpu14 |-CORE ID 2: cpu4 cpu16 | |-THREAD ID 0: cpu4 | \-THREAD ID 1: cpu16 |-CORE ID 8: cpu6 cpu18 | |-THREAD ID 0: cpu6 | \-THREAD ID 1: cpu18 |-CORE ID 9: cpu8 cpu20 | |-THREAD ID 0: cpu8 | \-THREAD ID 1: cpu20 \-CORE ID 10: cpu10 cpu22 |-THREAD ID 0: cpu10 \-THREAD ID 1: cpu22 And here are some tests. The differences are < 5% (but not so much): ############ enable smt ######## kern.usched_bsd4.smt_enable: 0 -> 1 tps = 53019.868091 (including connections establishing) tps = 52814.820895 (including connections establishing) tps = 53251.869806 (including connections establishing) tps = 53914.301869 (including connections establishing) tps = 53278.858660 (including connections establishing) tps = 53044.933921 (including connections establishing) tps = 53758.093953 (including connections establishing) tps = 53965.776254 (including connections establishing) tps = 53093.809461 (including connections establishing) tps = 53322.645105 (including connections establishing) ############ disable smt ######## kern.usched_bsd4.smt_enable: 1 -> 0 tps = 51379.980647 (including connections establishing) tps = 50960.834688 (including connections establishing) tps = 51336.041880 (including connections establishing) tps = 51311.336021 (including connections establishing) tps = 51227.944502 (including connections establishing) tps = 50828.181685 (including connections establishing) tps = 51342.268742 (including connections establishing) tps = 50887.898412 (including connections establishing) tps = 50667.897897 (including connections establishing) tps = 50960.282830 (including connections establishing) --14dae934116f99a22a04c5fbba48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

--14dae934116f99a22a04c5fbba48-- From vishesh3y at gmail.com Mon Jul 30 08:31:48 2012 From: vishesh3y at gmail.com (Vishesh Yadav) Date: Mon, 30 Jul 2012 21:01:48 +0530 Subject: [GSoC] inotify and fs indexing service status Message-ID: <24badc521b119c285c3a8cb971e7cce7@NO-ID-FOUND.mhonarc.org> --f46d0401696393fbe404c60dc229 Content-Type: text/plain; charset=ISO-8859-1 Hello, This week I worked on idr library and it now seems ready to work and is Linux compatible (except idr_pre_get() which takes one less argument than and the return codes.). Vishesh On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav wrote: > Hello, > > This week I worked on finding and fixing few pending issues, and worked > on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding > these two together using cookie parament in inotify_event which I'm > hoping should be completed by today or tomorrow. > > Vishesh > > On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote: > > Date: Mon, 16 Jul 2012 08:32:00 +0530 > > From: Vishesh Yadav > > To: kernel at crater.dragonflybsd.org > > Subject: Re: [GSoC] inotify and fs indexing service status > > > > Hello, > > > > This week I completed work on IN_CREATE and did some testing on inotify > > and found few bugs. IN_CREATE created some new bugs too on which I'm > > currently working on. > > > > Vishesh > > > > On 07/08/2012 09:41 PM, Vishesh Yadav wrote: > > > Hello, > > > > > > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These flags > > > required some workaround as their behavior required a little more > > > information than what is offered by kevent. There were few more > problems > > > with this including the merging of events in kqueue for which I'm > trying to > > > find a viable solution. > > > > > > Vishesh > > > > > > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav > wrote: > > > > > >> Hello, > > >> > > >> I wasn't able to put much work on code last week. Did some work on man > > >> pages. > > >> > > >> Vishesh > > >> > > >> > > >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav >wrote: > > >> > > >>> Hello, > > >>> > > >>> In fifth week I implement idr - integer management library using > code of > > >>> file descriptor allocators in kern_descrip.c. Worked to use the new > library > > >>> to be used with filedesc, however something or other didn't work > out. Will > > >>> be trying that again after looking at code more properly. Rest tested > > >>> existing work done till now which seems to work quite fine. There are > > >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED_FROM, > which I'm > > >>> being able to detect however have to synchronise them both using > cookie > > >>> argument. > > >>> > > >>> Vishesh > > >>> > > >>> > > >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav >wrote: > > >>> > > >>>> Hello, > > >>>> > > >>>> This week's status - > > >>>> > > >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS, > > >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with > Hammer > > >>>> and UFS. > > >>>> > > >>>> * Implemented inotify_read() and have the most important masks > working. > > >>>> Hence now we have a working inotify system. > > >>>> > > >>>> Vishesh > > >>>> > > >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote: > > >>>>> Hello, > > >>>>> > > >>>>> Not much new code this week. Improved and tested existing code, > exposed > > >>>>> watch/instance limits through sysctl and made the system respect > the > > >>>> limits. > > >>>>> > > >>>>> Rest studied kernel kqueue interface and its usage to be used in > > >>>>> inotify_read. Planned to add few knotes like NOTE_ACCESS, > NOTE_CLOSE > > >>>> and > > >>>>> linux like idr integer management that can be used in fdalloc and > watch > > >>>>> descriptors. > > >>>>> > > >>>>> Regards, > > >>>>> Vishesh > > >>>>> > > >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote: > > >>>>>> Hello, > > >>>>>> > > >>>>>> This week I finished watch management functions. Now watches can > be > > >>>> added, > > >>>>>> removed from into the inotify_instance. Hence inotify_add_watch, > > >>>>>> inotify_rm_watch are now almost complete. Just have to check error > > >>>> codes > > >>>>>> that are being returned. I also implemented fo_close for inotify > > >>>> fileops > > >>>>>> which cleans up the instance well now. > > >>>>>> > > >>>>>> Regards, > > >>>>>> Vishesh > > >>>>>> > > >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav < > vishesh3y at gmail.com> > > >>>> wrote: > > >>>>>> > > >>>>>>> Hello everyone, > > >>>>>>> > > >>>>>>> Current status for first week - > > >>>>>>> > > >>>>>>> - Repository and wiki setup at Github[1] > > >>>>>>> - Made the basic skeleton for inotify interface - system calls, > > >>>> helper > > >>>>>>> functions, structures, headers and few basic stuff in there. > > >>>>>>> - Currently working on management of watches (will be using > separate > > >>>>>>> file tables for watches). Once this is done, can write some > working > > >>>> code. > > >>>>>>> > > >>>>>>> In community bonding period, I setup my working environment, > browse > > >>>> and > > >>>>>>> understood relevant kernel codebase and studied Linux early and > > >>>> recent > > >>>>>>> inotify implementation. > > >>>>>>> > > >>>>>>> Now that exams are almost over, I hope I can catch up some pace > now. > > >>>>>>> > > >>>>>>> Regards, > > >>>>>>> Vishesh > > >>>>>>> > > >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/ > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > > > > > > > > -- > -Vishesh > --f46d0401696393fbe404c60dc229 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

This week I worked on idr library and it now seems ready to w= ork and is Linux compatible (except idr_pre_get() which takes one less argu= ment than and the return codes.).

Vishesh

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

--f46d0401696393fbe404c60dc229-- From pjd at EuroBSDconFoundation.org Mon Jul 30 14:53:25 2012 From: pjd at EuroBSDconFoundation.org (Pawel Jakub Dawidek) Date: Mon, 30 Jul 2012 23:53:25 +0200 Subject: EuroBSDcon 2012 registration is now open! Message-ID: Hello. I'm pleased to announce that the registration for the EuroBSDcon 2012 conference in Warsaw, Poland is now officially open! You can find all information about the conference at its official website: http://2012.eurobsdcon.org/ More frequent updates will be posted to the conference's Facebook page: https://www.facebook.com/pages/EuroBSDcon/171013546286700 and on Twitter: @eurobsdcon or via the twitter website https://twitter.com/eurobsdcon You can register at: http://2012.eurobsdcon.org/register/ You can find the conference program at: http://2012.eurobsdcon.org/agenda/talks/ http://2012.eurobsdcon.org/agenda/tutorials/ The official hotel for the conference is Novotel Warszawa Centrum, which is located in the exact city center and within walking distance from the venue. You can find more information about the hotels at: http://2012.eurobsdcon.org/venue/hotels/ To make use of the special offer, follow the instructions that page. You can find more info about getting to and moving around Warsaw at: http://2012.eurobsdcon.org/venue/transport/ Thanks to our generous sponsors and Poland's low costs, this year's EuroBSDcon is a bargain! This is also why we expect the conference to be very popular. If you want to be sure to attend, we strongly recommend that you register early. Please do not delay hotel booking either, as our pool of available rooms will be dropping quickly. It is very important that you book your room as soon as possible. Poland is part of the European Union and belongs to the Schengen Area, so in most cases people will have no problem visiting Poland. However to avoid surprises, we strongly recommend that you check whether you will need a visa. In case you do, the conference can provide a letter of invitation upon a request sent to info at eurobsdcon.org once you complete the registration process and pay the conference fee. This conference would not be possible without our sponsors: Platinum sponsors: EMC http://www.emc.com iXsystems http://www.ixsystems.com Wheel Systems http://www.wheelsystems.com Gold sponsors: The FreeBSD Foundation http://www.freebsdfoundation.org Silver sponsors: BSDeurope.eu http://www.bsdeurope.eu Google http://www.google.com Bronze sponsors: Madison Gurkha http://www.madison-gurkha.com pfSense http://www.pfSense.org The NetBSD Foundation http://www.netbsd.org USENIX http://www.usenix.org Media partners: BSD Magazine http://www.bsdmag.org Thank you! -- Pawel Jakub Dawidek EuroBSDcon Foundation From ivansichfreitas at gmail.com Mon Jul 30 23:41:39 2012 From: ivansichfreitas at gmail.com (Ivan S. Freitas) Date: Tue, 31 Jul 2012 03:41:39 -0300 Subject: [GSoC] 32 bit api status Message-ID: Sorry for the late response, but I had some issues with my notebook. > could you please elaborate a bit more on your progress? What works? > What doesn't? Which syscalls are still broken? Which ones have been > ported? Do you have some spreadsheet or something like that with that > information? I've translated (but not tested) kevent, pselect, select, sigaltstack, gettimeofday and getrusage, plus about a dozen helper functions. The helpers themselves took more work than the syscalls, also the overall structure needed a lot of work to be functional (at least partially). So far it isn't possible to run a complete application using this layer yet. > What are your plans for the next 1 or 2 weeks? My classes are starting again this week, so I may be only available at night. I don't think it will be possible to run a complete in the end (I'm aware that is not enough to pass in the final evaluation), so I'll focus on creating an program to test the already translated syscalls. I will stay and finish this even after GSoC ends, I just think that I bit off more than I could chew. -- Ivan Sichmann Freitas GNU/Linux user #509059 From mihai.carabas at gmail.com Sun Jul 1 09:37:27 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sun, 1 Jul 2012 19:37:27 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: --14dae9340eb703939604c3c74c9f Content-Type: text/plain; charset=ISO-8859-1 Hi, I fixed the bugs regarding the CPU Topology on monster (here [1] you have the cpu topology sysctl output from the monster). There were multiple problems: - one bug that I introduced when I did the refactoring in order to add support for cpu topology to the vkernel - I considered that the APICIDs are starting from 0 (in this case the APICIDs were starting from 16) - I considered that the APICIDs are consecutive (in this case they weren't...because the number of cores/cpu isn't a power of two, so it had to be skipped some ids between different physical cpus) - I found a bug in "sbuf_vprintf". If the sbuf is auto expandable and if there isn't enough space to put all the data, the sbuf is expanded and give another try. The problem is that the va_list "ap" may be left in an inconsistent state (va_arg() only iterated through some of the arguments) and the print of the arguments would be wrong. I have made a fix, using a copy of the "ap" [2]. (Alex H, I think this commit must go to master if I am right). PS: Matthew thanks a lot for the monster. You can shut it down now:). I don't have any heuristics for core/chip cache coherence right now to do performance testing. [1] http://leaf.dragonflybsd.org/~mihaic/monster_cpu_topology [2] https://github.com/mihaicarabas/dragonfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490 --14dae9340eb703939604c3c74c9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

- I considered that the APICIDs ar= e consecutive (in this case they weren't...because the number of cores/= cpu isn't a power of two, so it had to be skipped some ids between diff= erent physical cpus)

- I found a bug in "sbuf_vprintf". If the sbuf is auto expan= dable and if there isn't enough space to put all the data, the sbuf is = expanded and give another try. The problem is that the va_list "ap&quo= t; may be left in an inconsistent state (va_arg() only iterated through som= e of the arguments) and the print of the arguments would be wrong. I have m= ade a fix, using a copy of the "ap" [2]. (Alex H, I think this co= mmit must go to master if I am right).

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

--14dae9340eb703939604c3c74c9f-- From ivansichfreitas at gmail.com Mon Jul 2 05:04:48 2012 From: ivansichfreitas at gmail.com (Ivan Sichmann Freitas) Date: Mon, 2 Jul 2012 09:04:48 -0300 Subject: [GSoC] 32 bit api status Message-ID: --ZG5hGh9V5E9QzVHS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I'm still working on importing as much FreeBSD's syscalls as possible, not everything is committed since most of it still broken (mostly because of types that I need to convert to 32bit). --=20 Ivan Sichmann Freitas GNU/Linux user #509059 --ZG5hGh9V5E9QzVHS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJP8Y5gAAoJEFM7yh3+vhFAfLcP/2teFJgSFeU1srWlbwI180j1 I3F35tW92uGKw0Gh5mEqdaA6ULYXAYGZk6gIPE8C2vDgwxztpsqnfD97ZOs4nsiq eUbjqRc/vFtaOA5YmGhgX9OdQgmahzDYWCS2iBLpLvMCcRhtcF3LWbJD/LIbm9MS csbihAcyo/Pf5wjUiPcavIZMW6G9m59SgA6ntH0tVvRrq+EWAI3jJG1UC1pbFJLz y603oE/kP1uiWNG4k3fz6zAKfRmj7Am5ag8lx65uRf7KgJTK+7ll1E0QRQE6a6vq LUsKpRPQpSiR6hrKzqBx2b5mmkEap/iPNbQaEvYjm3jC3VxC0Q5VlcbMh/AUFe1n 1JoruoYjLcRXPLNbFF29K9AzBcWhbeRRBE2wft+rDjZWJGYpqrbkLzDHqo2K874x LtV1BAqfCEDGPuKoj/8fC4Io8KOCZyftdU5imOIifhqiWrZuAkB5lFg97EOU97fI NDwJ8dh+CNR8+EDxr7CUgd+dCqBdFY5wy9CI+f3EdQrmYtFzJ5P9kiQA3J8M3JNL 1CTksDiB+xm6MZeVjE7rakV2s+zFNK39rLiZQfzKfhDv7utWNY8xoc7NpLFFEYDz 7ULVE+G3zogICUPZ+/MngdRhaQEF66d/nLGaqJMzNIPqGYsZ7CgB6wI1KPRY6Klp 7jDPN7M/2w4qdjhi3BCZ =EPGl -----END PGP SIGNATURE----- --ZG5hGh9V5E9QzVHS-- From vishesh3y at gmail.com Mon Jul 2 23:40:40 2012 From: vishesh3y at gmail.com (Vishesh Yadav) Date: Tue, 3 Jul 2012 12:10:40 +0530 Subject: [GSoC] inotify and fs indexing service status Message-ID: --f46d042f927a6d46b504c3e73104 Content-Type: text/plain; charset=ISO-8859-1 Hello, I wasn't able to put much work on code last week. Did some work on man pages. Vishesh On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav wrote: > Hello, > > In fifth week I implement idr - integer management library using code of > file descriptor allocators in kern_descrip.c. Worked to use the new library > to be used with filedesc, however something or other didn't work out. Will > be trying that again after looking at code more properly. Rest tested > existing work done till now which seems to work quite fine. There are > mainly two events left to handle IN_MOVED_TO and IN_MOVED_FROM, which I'm > being able to detect however have to synchronise them both using cookie > argument. > > Vishesh > > > On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav wrote: > >> Hello, >> >> This week's status - >> >> * Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS, >> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer >> and UFS. >> >> * Implemented inotify_read() and have the most important masks working. >> Hence now we have a working inotify system. >> >> Vishesh >> >> On 06/10/2012 11:42 PM, Vishesh Yadav wrote: >> > Hello, >> > >> > Not much new code this week. Improved and tested existing code, exposed >> > watch/instance limits through sysctl and made the system respect the >> limits. >> > >> > Rest studied kernel kqueue interface and its usage to be used in >> > inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE and >> > linux like idr integer management that can be used in fdalloc and watch >> > descriptors. >> > >> > Regards, >> > Vishesh >> > >> > On 06/03/2012 10:14 PM, Vishesh Yadav wrote: >> >> Hello, >> >> >> >> This week I finished watch management functions. Now watches can be >> added, >> >> removed from into the inotify_instance. Hence inotify_add_watch, >> >> inotify_rm_watch are now almost complete. Just have to check error >> codes >> >> that are being returned. I also implemented fo_close for inotify >> fileops >> >> which cleans up the instance well now. >> >> >> >> Regards, >> >> Vishesh >> >> >> >> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav >> wrote: >> >> >> >>> Hello everyone, >> >>> >> >>> Current status for first week - >> >>> >> >>> - Repository and wiki setup at Github[1] >> >>> - Made the basic skeleton for inotify interface - system calls, helper >> >>> functions, structures, headers and few basic stuff in there. >> >>> - Currently working on management of watches (will be using separate >> >>> file tables for watches). Once this is done, can write some working >> code. >> >>> >> >>> In community bonding period, I setup my working environment, browse >> and >> >>> understood relevant kernel codebase and studied Linux early and recent >> >>> inotify implementation. >> >>> >> >>> Now that exams are almost over, I hope I can catch up some pace now. >> >>> >> >>> Regards, >> >>> Vishesh >> >>> >> >>> [1] https://github.com/vishesh/DragonFlyBSD/ >> >>> >> >> >> > >> > >> >> >> > --f46d042f927a6d46b504c3e73104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

Vishesh

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

--f46d042f927a6d46b504c3e73104-- From mihai.carabas at gmail.com Sun Jul 8 02:29:36 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sun, 8 Jul 2012 12:29:36 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <1c276d66f2810b328a5aac99fcfd5156@NO-ID-FOUND.mhonarc.org> --14dae9340eb7cd53b804c44e2225 Content-Type: text/plain; charset=ISO-8859-1 Hello, This week I worked on an heuristic that sounds like this: always schedule a process to the closest cpu relatively to the cpu it had run before.(e.g.: try to run on the cpu that had run before, if it isn't free, try on it's sibling on the current level (let's say thread level), if no sibling was found, go to the next level (which is the core level), and so on). So, in other words, the process would be scheduled to the closest cache it can (it couldn't be scheduled on the same core, will loose the level1 cache hotness, but it can use the level3 cache hotness). Unfortunately, I couldn't find a case to make a difference on my corei3. The reason would be that the time quanta of a process is big enough in dragonfly that a process that is scheduled is able to use a great part of the L1/L2 cache and on a context switch the cache will be invalidated. With the L3 cache shared among all cores, there will be no gain. I am waiting for access on a multi-socket machine, to test it there. --14dae9340eb7cd53b804c44e2225 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

This week I worked on an heuristic that sounds like this= : always schedule a process to the closest cpu relatively to the cpu it had= run before.(e.g.: try to run on the cpu that had run before, if it isn'= ;t free, try on it's sibling on the current level (let's say thread= level), if no sibling was found, go to the next level (which is the core l= evel), and so on). So, in other words, the process would be scheduled to th= e closest cache it can (it couldn't be scheduled on the same core, will= loose the level1 cache hotness, but it can use the level3 cache hotness). = Unfortunately, I couldn't find a case to make a difference on my corei3= . The reason would be that the time quanta of a process is big enough in dr= agonfly that a process that is scheduled is able to use a great part of the= L1/L2 cache and on a context switch the cache will be invalidated. With th= e L3 cache shared among all cores, there will be no gain. I am waiting for = access on a multi-socket machine, to test it there.

--14dae9340eb7cd53b804c44e2225-- From nuno.antunes at gmail.com Sun Jul 8 06:12:33 2012 From: nuno.antunes at gmail.com (Nuno Antunes) Date: Sun, 8 Jul 2012 17:12:33 +0400 Subject: Question about lwkt_domsg() Message-ID: <4af1b2850722b4b850abb5293462919f@NO-ID-FOUND.mhonarc.org> Hi, lwkt_domsg() comment reads like this, /* * lwkt_domsg() * * Request asynchronous completion and call lwkt_beginmsg(). The * target port can opt to execute the message synchronously or * asynchronously and this function will automatically queue the * response if the target executes the message synchronously. */ However, in the function body, the sync flag is set: [...] msg->ms_flags |= MSGF_SYNC; [...] Should the comment read instead "Request synchronous completion [...]" ? Thanks Nuno From vishesh3y at gmail.com Sun Jul 8 09:11:06 2012 From: vishesh3y at gmail.com (Vishesh Yadav) Date: Sun, 8 Jul 2012 21:41:06 +0530 Subject: [GSoC] inotify and fs indexing service status Message-ID: <658288c8c1adbe0eb4da460ee26e7c68@NO-ID-FOUND.mhonarc.org> --f46d040167f5a0a28a04c453be3e Content-Type: text/plain; charset=ISO-8859-1 Hello, This week I worked on NOTE_CREATE and IN_MOVED_* flags. These flags required some workaround as their behavior required a little more information than what is offered by kevent. There were few more problems with this including the merging of events in kqueue for which I'm trying to find a viable solution. Vishesh On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav wrote: > Hello, > > I wasn't able to put much work on code last week. Did some work on man > pages. > > Vishesh > > > On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav wrote: > >> Hello, >> >> In fifth week I implement idr - integer management library using code of >> file descriptor allocators in kern_descrip.c. Worked to use the new library >> to be used with filedesc, however something or other didn't work out. Will >> be trying that again after looking at code more properly. Rest tested >> existing work done till now which seems to work quite fine. There are >> mainly two events left to handle IN_MOVED_TO and IN_MOVED_FROM, which I'm >> being able to detect however have to synchronise them both using cookie >> argument. >> >> Vishesh >> >> >> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav wrote: >> >>> Hello, >>> >>> This week's status - >>> >>> * Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS, >>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer >>> and UFS. >>> >>> * Implemented inotify_read() and have the most important masks working. >>> Hence now we have a working inotify system. >>> >>> Vishesh >>> >>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote: >>> > Hello, >>> > >>> > Not much new code this week. Improved and tested existing code, exposed >>> > watch/instance limits through sysctl and made the system respect the >>> limits. >>> > >>> > Rest studied kernel kqueue interface and its usage to be used in >>> > inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE >>> and >>> > linux like idr integer management that can be used in fdalloc and watch >>> > descriptors. >>> > >>> > Regards, >>> > Vishesh >>> > >>> > On 06/03/2012 10:14 PM, Vishesh Yadav wrote: >>> >> Hello, >>> >> >>> >> This week I finished watch management functions. Now watches can be >>> added, >>> >> removed from into the inotify_instance. Hence inotify_add_watch, >>> >> inotify_rm_watch are now almost complete. Just have to check error >>> codes >>> >> that are being returned. I also implemented fo_close for inotify >>> fileops >>> >> which cleans up the instance well now. >>> >> >>> >> Regards, >>> >> Vishesh >>> >> >>> >> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav >>> wrote: >>> >> >>> >>> Hello everyone, >>> >>> >>> >>> Current status for first week - >>> >>> >>> >>> - Repository and wiki setup at Github[1] >>> >>> - Made the basic skeleton for inotify interface - system calls, >>> helper >>> >>> functions, structures, headers and few basic stuff in there. >>> >>> - Currently working on management of watches (will be using separate >>> >>> file tables for watches). Once this is done, can write some working >>> code. >>> >>> >>> >>> In community bonding period, I setup my working environment, browse >>> and >>> >>> understood relevant kernel codebase and studied Linux early and >>> recent >>> >>> inotify implementation. >>> >>> >>> >>> Now that exams are almost over, I hope I can catch up some pace now. >>> >>> >>> >>> Regards, >>> >>> Vishesh >>> >>> >>> >>> [1] https://github.com/vishesh/DragonFlyBSD/ >>> >>> >>> >> >>> > >>> > >>> >>> >>> >> > --f46d040167f5a0a28a04c453be3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

This week I worked on NOTE_CREATE and IN_MOVED_* flags. These= flags required some workaround as their behavior required a little more in= formation than what is offered by kevent. There were few more problems with= this including the merging of events in kqueue for which I'm trying to= find a viable solution.

Vishesh

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

--f46d040167f5a0a28a04c453be3e-- From dillon at apollo.backplane.com Mon Jul 9 21:37:58 2012 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Mon, 9 Jul 2012 21:37:58 -0700 (PDT) Subject: Question about lwkt_domsg() Message-ID: :Hi, : :lwkt_domsg() comment reads like this, : :... :Should the comment read instead "Request synchronous completion [...]" ? : :Thanks :Nuno Yes, the comment is wrong. -Matt Matthew Dillon From ivansichfreitas at gmail.com Tue Jul 10 01:02:27 2012 From: ivansichfreitas at gmail.com (Ivan Sichmann Freitas) Date: Tue, 10 Jul 2012 05:02:27 -0300 Subject: [GSoC] 32 bit api status Message-ID: --uZ3hkaAS1mZxFaxD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, Sorry for the late message, but I almost finished importing freebsd's syscalls, I hope to have something running soon. --=20 Ivan Sichmann Freitas GNU/Linux user #509059 --uZ3hkaAS1mZxFaxD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJP++GTAAoJEFM7yh3+vhFA8boP/RrHf7Lb3wlAiKLc3d7i4hki ZOGWk1vHtNcBYJwW8nmOaxe3UVksBLn8wf52Vj/eD/xtEp7KUzTnkbSjPJY5RX1H OUekdf/RE0/VFhzA2ZHsjz9NL2hzPOw6gyN0OW9h7qVWi2X1sPMrdenspPqKeqlm in3L9ZIkqP3uB7WctO8cDFGwKfmmeGcoVhbhqK7yCYHus9TBsAY+qoxULlMiQK20 G5AK8LxS4AQs2ykcDBNhdxR0qgy6tCs+n6Jg+b+iom0FWAWCHG1NrzSLvtQO1vd5 YKtCvril6WkPJ1PGPyLgipAD62c5Cqmh83lyboBQGaKJVpa7RdiILPlNIth2qTaF lyo7lHAmtN0aowMS5sv6tRHGkZ1mvoBexrU50Q+hFIPJN7Thz7IwgFk4eIz59zPO BHhawZUVyNGz7PN9V+2IYYc7BnKcB3WQpjbD9LbbNZ3zfI5lVJH8ESACJQUIAKxi Gv82WHnJ42d6XsOAVpgG/VpS+ERWkw5rrvUQu8slJwHMK4i5Csilw6B+GHTEw8pW feNqwqR9GBOrWyNBV4q2uCpXiKsJ5R26skC2YEMAXIezNUi5FxWO/PMqbbR7fNu+ RRhKYKEGCLFB6yDAnSimeYMQkCdnrE/yXreP1QLFnZTQ2XW4RWdTPsswK4rF5aeb adiN8SuDw62Afkqu+n0o =t8LF -----END PGP SIGNATURE----- --uZ3hkaAS1mZxFaxD-- From mihai.carabas at gmail.com Fri Jul 13 20:23:31 2012 From: mihai.carabas at gmail.com (Mihai Carabas) Date: Sat, 14 Jul 2012 06:23:31 +0300 Subject: GSoC: Add SMT/HT awareness to DragonFlyBSD scheduler Message-ID: <92dea7d0ff0a7c5f3ce2ca4756a488f1@NO-ID-FOUND.mhonarc.org> --90e6ba6148a699dc3804c4c1b8bc Content-Type: text/plain; charset=ISO-8859-1 Hello, On Sun, Jul 8, 2012 at 12:29 PM, Mihai Carabas wrote: > Hello, > > This week I worked on an heuristic that sounds like this: always schedule > a process to the closest cpu relatively to the cpu it had run before.(e.g.: > try to run on the cpu that had run before, if it isn't free, try on it's > sibling on the current level (let's say thread level), if no sibling was > found, go to the next level (which is the core level), and so on). So, in > other words, the process would be scheduled to the closest cache it can (it > couldn't be scheduled on the same core, will loose the level1 cache > hotness, but it can use the level3 cache hotness). Unfortunately, I > couldn't find a case to make a difference on my corei3. The reason would be > that the time quanta of a process is big enough in dragonfly that a process > that is scheduled is able to use a great part of the L1/L2 cache and on a > context switch the cache will be invalidated. With the L3 cache shared > among all cores, there will be no gain. I am waiting for access on a > multi-socket machine, to test it there. > This week I haven't done much coding. I tested the heuristic above on monster (thanks dillon) and on a dual-socket (thanks ftigeot) amd but the results weren't meaningful. I start adding debug info to see what happens. It seems that the processes bumps from one CPU to another when there are more processes than cpus (the setrunqueue bits is the active mechanism for scheduling, but there is another one - when a process finishes or blocks, that CPU tries and pull a process from the bsd4 runqueue, but that process didn't run before on this CPU). I have discussed the issue with Alex and Matthew and I am currently working out on a solution. --90e6ba6148a699dc3804c4c1b8bc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

This week I haven't done much cod= ing. I tested the heuristic above on monster (thanks dillon) and on a dual-= socket (thanks ftigeot)=A0amd but the results weren't meaningful. I sta= rt adding debug info to see what happens. It seems that the processes bumps= from one CPU to another when there are more processes than cpus (the setru= nqueue bits is the active mechanism for scheduling, but there is another on= e - when a process finishes or blocks, that CPU tries and pull a process fr= om the bsd4 runqueue, but that process didn't run before on this CPU). = I have discussed the issue with Alex and Matthew and I am currently working= out on a solution.

--90e6ba6148a699dc3804c4c1b8bc-- From vishesh3y at gmail.com Sun Jul 15 20:02:00 2012 From: vishesh3y at gmail.com (Vishesh Yadav) Date: Mon, 16 Jul 2012 08:32:00 +0530 Subject: [GSoC] inotify and fs indexing service status Message-ID: Hello, This week I completed work on IN_CREATE and did some testing on inotify and found few bugs. IN_CREATE created some new bugs too on which I'm currently working on. Vishesh On 07/08/2012 09:41 PM, Vishesh Yadav wrote: > Hello, > > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These flags > required some workaround as their behavior required a little more > information than what is offered by kevent. There were few more problems > with this including the merging of events in kqueue for which I'm trying to > find a viable solution. > > Vishesh > > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav wrote: > >> Hello, >> >> I wasn't able to put much work on code last week. Did some work on man >> pages. >> >> Vishesh >> >> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav wrote: >> >>> Hello, >>> >>> In fifth week I implement idr - integer management library using code of >>> file descriptor allocators in kern_descrip.c. Worked to use the new library >>> to be used with filedesc, however something or other didn't work out. Will >>> be trying that again after looking at code more properly. Rest tested >>> existing work done till now which seems to work quite fine. There are >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED_FROM, which I'm >>> being able to detect however have to synchronise them both using cookie >>> argument. >>> >>> Vishesh >>> >>> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav wrote: >>> >>>> Hello, >>>> >>>> This week's status - >>>> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS, >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer >>>> and UFS. >>>> >>>> * Implemented inotify_read() and have the most important masks working. >>>> Hence now we have a working inotify system. >>>> >>>> Vishesh >>>> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote: >>>>> Hello, >>>>> >>>>> Not much new code this week. Improved and tested existing code, exposed >>>>> watch/instance limits through sysctl and made the system respect the >>>> limits. >>>>> >>>>> Rest studied kernel kqueue interface and its usage to be used in >>>>> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE >>>> and >>>>> linux like idr integer management that can be used in fdalloc and watch >>>>> descriptors. >>>>> >>>>> Regards, >>>>> Vishesh >>>>> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote: >>>>>> Hello, >>>>>> >>>>>> This week I finished watch management functions. Now watches can be >>>> added, >>>>>> removed from into the inotify_instance. Hence inotify_add_watch, >>>>>> inotify_rm_watch are now almost complete. Just have to check error >>>> codes >>>>>> that are being returned. I also implemented fo_close for inotify >>>> fileops >>>>>> which cleans up the instance well now. >>>>>> >>>>>> Regards, >>>>>> Vishesh >>>>>> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav >>>> wrote: >>>>>> >>>>>>> Hello everyone, >>>>>>> >>>>>>> Current status for first week - >>>>>>> >>>>>>> - Repository and wiki setup at Github[1] >>>>>>> - Made the basic skeleton for inotify interface - system calls, >>>> helper >>>>>>> functions, structures, headers and few basic stuff in there. >>>>>>> - Currently working on management of watches (will be using separate >>>>>>> file tables for watches). Once this is done, can write some working >>>> code. >>>>>>> >>>>>>> In community bonding period, I setup my working environment, browse >>>> and >>>>>>> understood relevant kernel codebase and studied Linux early and >>>> recent >>>>>>> inotify implementation. >>>>>>> >>>>>>> Now that exams are almost over, I hope I can catch up some pace now. >>>>>>> >>>>>>> Regards, >>>>>>> Vishesh >>>>>>> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/ >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> > From ivansichfreitas at gmail.com Mon Jul 16 06:50:19 2012 From: ivansichfreitas at gmail.com (Ivan Sichmann Freitas) Date: Mon, 16 Jul 2012 10:50:19 -0300 Subject: [GSoC] 32 bit api status Message-ID: <645e6c8edddfcc14810ad8b937724a65@NO-ID-FOUND.mhonarc.org> --GID0FwUMdk1T2AWN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, This week I reorganized m patches, and I'm still fixing issues with imported FreeBSD's syscalls. --=20 Ivan Sichmann Freitas GNU/Linux user #509059 --GID0FwUMdk1T2AWN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJQBBwbAAoJEFM7yh3+vhFAiIMP/3BvgESluVQR0oQTwZsKYaBN dkoONlU/WN1BtqjrzBRd1LpVUqpwybSQIOQgnlOG+37A/MMlCFX2vbs1LNQXX31b pWjhWbEdd4jRMalCbq9xK84Q7OztLoNP1AEohjFpqttG6ii0TTkbBK5iccTjyUpc 2l6P0ffJqROnQ/K30jh005+1LcVvlhjjILmaK0ubIYaAlWV3NHWBTLX4PJOhvauQ riIdfCRg5sXr2lNkMCLilTchViRVvhwMZ8hR2gJcYwPnBP0xvjy+pPtxwq/BM/XX ykuoom8ZTpBrDZWaabR7BYKgHcIKVnLJZwAN0EH4XhIytleMC5bUm7uYejBcME+t wpbqUfaL5VybQKviI7BSjM1LQdZuA+GOfuoTeVJh3WKIFQkDyCn1KZTHS2crXzHm ehQ+DnRubL4HaAYbi4DdqSOtZuWytee/F5SDZqLgjCFjaey1t7Vr9dvFeF3hkPA8 mw5fAyO1+cMblOGB+ajwHfWSwcKt/hYGxEvV78pegyQLVrcyUG9AH+GeVvq6m6nG X+dMrNeA5JliYbbH1FRL/UoTSakl2NuTdc77cKP4frThSZt5jMeiZFcGqkqi1HVm BFcpuEz5sSiR6sKy/Y1kYznJWxm/6s/IIrQvd+RKlb01yOoGiG7E/MVo0mkx0p8Y KSbPlyNrt8I7y7sGtMzF =Iv9o -----END PGP SIGNATURE----- --GID0FwUMdk1T2AWN-- From markus.pfeiffer at morphism.de Tue Jul 17 01:11:13 2012 From: markus.pfeiffer at morphism.de (Markus Pfeiffer) Date: Tue, 17 Jul 2012 08:11:13 +0000 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: <9ac2b41993475ba0b437189d2dc8650f@NO-ID-FOUND.mhonarc.org> --JP+T4n/bALQSJXh8 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear all, (I think in particular Matt and Alex H.) while porting drivers from FreeBSD some of us have stumbled over the functi= ons devfs_get_cdevpriv and devfs_set_cdevpriv, which store some per-open-filedescriptor information for some devices. I looked into the FreeBSD code and the implementation seems weird to me sin= ce they store the filedescriptor on syscall in their thread struct and the fun= ctions rely on that hidden state. Question is now: Should we have similar functionality (i.e. per open filedescriptor "private" data) and if yes how to best implement that. I know that AlexH had made some suggestion but I cannot find it in the IRC logs and it would probably be more efficient doing this by mail.=20 Markus --=20 Markus Pfeiffer, University of St Andrews email: markus.pfeiffer at morphism.de | xmpp: markus.pfeiffer at jabber.morphism.= de --JP+T4n/bALQSJXh8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) iQIcBAEBAgAGBQJQBR4hAAoJEEYIAIuHgtZG6F8P/0fpa44NuDXRaGZ5Qka97oQv vXzFWkcqbLObj/q+Fi1XIlHlJpb4jTeaHUlJQBMo3laVJVPg7jBSeva1o+KC8YgQ N9ISsr39xaiIIMY64m/bWPIEx6jA7nChmALgjRmvgPUkEZply02Mi/5GaTEY28dO jeZZ037XWJ3d9u851qYBhVCIMIbpTvIhTlhpEdxmwDYzHqtoa0qI6s6gbq0jcE/2 W1UmXg/lrsJfi1plp4zj9R5Erx6SOILeT4nDPKyLnGlV5lg0O5SgEApAbsPGN+DC dseDt6YZC+xaMjsLuY1fVecuLZ0TX65aGLHNnRATS8ZVWa/LIGN3Ig/e2/M8GcCY MVYEo+uw5EhNfmfNuDaNnqq/9mjmrnR8Z7gWZM5yOuPGxs4IkI1A6csxLQAEgott AUdwpV9CV6q8iTPAFhXyy2N6dRFWDDcZpzLgVFJHbgvNq5c+uKbHAXgW5lJlzfjk wfBnUow3oGL+UricJ4RxMeDZGw0T6E103iIHVUtpdehJxKN5tg3Pz/tVq52mKmA5 S1BayCVmQP5xqSUXa8i17+EE/TabpwO/4AnymZmtsjfB4QQ4YM//eQRd5jmQkMTO BrudzeZ5spubeQHBcVpIUASXo3aLoJeZJQoZ+UgtSV8AEcAd3tPeOcLi6ImLZTKH hl9A9mLKQYRc9HtPBH6y =LAf5 -----END PGP SIGNATURE----- --JP+T4n/bALQSJXh8-- From ftigeot at wolfpond.org Tue Jul 17 01:25:27 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Tue, 17 Jul 2012 10:25:27 +0200 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: <4e59e606fb0de44d6f59cc96f59f3905@NO-ID-FOUND.mhonarc.org> Hi, On Tue, Jul 17, 2012 at 08:11:13AM +0000, Markus Pfeiffer wrote: > > while porting drivers from FreeBSD some of us have stumbled over the functions > devfs_get_cdevpriv and devfs_set_cdevpriv, which store some > per-open-filedescriptor information for some devices. > > I looked into the FreeBSD code and the implementation seems weird to me since > they store the filedescriptor on syscall in their thread struct and the functions > rely on that hidden state. > > Question is now: Should we have similar functionality (i.e. per open > filedescriptor "private" data) and if yes how to best implement that. I know > that AlexH had made some suggestion but I cannot find it in the IRC logs and > it would probably be more efficient doing this by mail. I encountered the same family of functions while looking at recent FreeBSD DRM code; since it was ported from Linux in the first place, I also looked at the Linux equivalent functions, and they seemed much more sane. Private data was directly accessible from the filedescriptor if I remember correctly. -- Francois Tigeot From crogers122 at gmail.com Tue Jul 17 08:29:33 2012 From: crogers122 at gmail.com (Chris Rogers) Date: Tue, 17 Jul 2012 11:29:33 -0400 Subject: AES GCM/GMAC Message-ID: --e89a8ff1bf64a8054e04c50836de Content-Type: text/plain; charset=ISO-8859-1 All, In your AES GCM implementation, you have the following lines of code in cryptosoft.c, in fucntion swcr_combined(): ******* for (crd = crp->crp_desc; crd; crd = crd->crd_next) { for (sw = swcr_sessions[crp->crp_sid & 0xffffffff]; sw && sw->sw_alg != crd->crd_alg; sw = sw->sw_next) ; if (sw == NULL) return (EINVAL); switch (sw->sw_alg) { case CRYPTO_AES_GCM_16: case CRYPTO_AES_GMAC: swe = sw; crde = crd; exf = swe->sw_exf; ivlen = exf->blocksize; break; case CRYPTO_AES_128_GMAC: case CRYPTO_AES_192_GMAC: case CRYPTO_AES_256_GMAC: swa = sw; crda = crd; axf = swa->sw_axf; if (swa->sw_ictx == 0) return (EINVAL); bcopy(swa->sw_ictx, &ctx, axf->ctxsize); blksz = axf->blocksize; break; default: return (EINVAL); } } if (crde == NULL || crda == NULL) return (EINVAL); ******* My understanding of GCM and GMAC was that GMAC was an authentication only variant of GCM, and thus they were mutually exclusive. But, it looks like the rest of the function will never execute if GMAC isn't chosen as the mode of encryption. Does this mean that GCM uses GMAC as part of its standard encryption process, or is the encryption for GCM only implemented somewhere else? Any help on this matter would be greatly appreciated. Chris --e89a8ff1bf64a8054e04c50836de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

Last week I finished implementing the new heurist= ic about cache hotness and obtained some new results in pgbench benchmark:<= /div>

############enable smt########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 21= 651.867019 (including connections establishing)

tps =3D 21647.787= 878 (including connections establishing)

tps =3D 21588.095351 (in= cluding connections establishing)

tps =3D 21607.754026 (including connections establishing)

tp= s =3D 21625.132137 (including connections establishing)

tps =3D 2= 1765.227960 (including connections establishing)

tps =3D 21646.29= 2802 (including connections establishing)

tps =3D 21513.203674 (including connections establishing)

tp= s =3D 21666.282788 (including connections establishing)

tps =3D 2= 1656.393030 (including connections establishing)

#= ###########disable smt########

kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 20843.966453 = (including connections establishing)

tps =3D 20799.100980 (includ= ing connections establishing)

tps =3D 20705.922558 (including con= nections establishing)

tps =3D 20834.236784 (including connections establishing)

tp= s =3D 20780.154608 (including connections establishing)

tps =3D 2= 0854.064166 (including connections establishing)

tps =3D 20768.36= 2228 (including connections establishing)

tps =3D 20784.986692 (including connections establishing)

tp= s =3D 20802.228183 (including connections establishing)

tps =3D 2= 0823.033787 (including connections establishing)

Y= ou can see a difference of ~900-1000tps =3D 5%.

Note: tps - transactions per second - more is better.

= For this test I ran 4 threads for the server and 4 clients. 4 of them are C= PU-intensive and the other 4 are not. The tests were done on my Corei3.

There is no patch commited yet. I will come with another e-mail when i= s ready.

Thanks ftigeot for giving me access to a dual-socket op= teron (2 cpus). The results of testing:

#####= ####### enable smt ########

kern.usched_bsd4.smt_enable: 0 -> = 1

tps =3D 11505.350032 (including connections establishing)

tp= s =3D 12358.802902 (including connections establishing)

tps =3D 1= 0376.294593 (including connections establishing)

tps =3D 10329.97= 6654 (including connections establishing)

tps =3D 11552.765499 (including connections establishing)

--= ----------------------------------------------------

average =3D = 11224 tps

############ disable smt ########

<= div> kern.usched_bsd4.smt_enable: 1 -> 0

tps =3D 8950.803833 (inclu= ding connections establishing)

tps =3D 9573.479233 (including con= nections establishing)

tps =3D 8872.650887 (including connections= establishing)

tps =3D 10609.939778 (including connections establishing)

tp= s =3D 10686.083868 (including connections establishing)

---------= ----------------------------------------------

average =3D 9738 t= ps

The command used was:

pgbench -U pgsql -j 2 -= c 2 -T 60 -S bench100 -h 127.0.0.1 2> /dev/null | grep "including c= onnections establishing"

Another set of results on a core i7 (thanks Alex H):

I also obtained some better results on my core i3= than last week, but the location of my machine is out of internet now and = I don't have access to the results:(.

Hi,

=A0

This machine is an old-school dual-Opteron 252 system and doesn&= #39;t have
any hyperthreading support at all.

Its exact configuration is
=A0 - 2 sockets
=A0 - 1 core per socket (2.6 GHz, 1MB cache)
=A0 - 2GB of RAM per socket
=A0 - 1 thread per core

Having an hyperthreading-aware scheduler shouldn't make any difference;=
what could explain the above performance differences ?

Mihai

Here are some results from a AMD FX(tm)-8150 Eigh= t-Core Processor(thanks profkmax):

##########= ## enable smt ########

kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 32987.010952 (including connections establishing)

tp= s =3D 33072.952733 (including connections establishing)

tps =3D 3= 2693.574568 (including connections establishing)

tps =3D 33084.27= 7648 (including connections establishing)

tps =3D 33481.054536 (including connections establishing)

tp= s =3D 33013.296931 (including connections establishing)

tps =3D 3= 2711.982849 (including connections establishing)

tps =3D 32686.12= 0901 (including connections establishing)

tps =3D 32792.744933 (including connections establishing)

tp= s =3D 33367.284545 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.smt_enab= le: 1 -> 0

tps =3D 31364.873850 (including connections establishing)

tp= s =3D 31340.974524 (including connections establishing)

tps =3D 3= 1648.286265 (including connections establishing)

tps =3D 30913.78= 8400 (including connections establishing)

tps =3D 31338.052583 (including connections establishing)

tp= s =3D 31360.521337 (including connections establishing)

tps =3D 3= 1545.915474 (including connections establishing)

tps =3D 31489.00= 8958 (including connections establishing)

tps =3D 30657.108291 (including connections establishing)

tp= s =3D 31294.472379 (including connections establishing)

The difference is > 1500tps (5%).=A0

Here is an interesting CPU topology from a dual-socket XEON:

hw.cpu_topology.tree:

\-PACKAGE MEMBERS: cpu0 cpu1 cpu2 cpu3 cpu4 c= pu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11 cpu12 cpu13 cpu14 cpu15 cpu16 cpu17 cpu= 18 cpu19 cpu20 cpu21 cpu22 cpu23

=A0 |-CHIP ID 0: cpu1 cpu3 cpu5 cpu7 cpu9 cpu11 = cpu13 cpu15 cpu17 cpu19 cpu21 cpu23

=A0 | |= -CORE ID 0: cpu1 cpu13

=A0 | | |-THREAD ID = 0: cpu1

=A0 | | \-THREAD ID 1: cpu13

=A0 | |-CORE ID 1: cpu3 cpu15

= =A0 | | |-THREAD ID 0: cpu3

=A0 | | \-THREA= D ID 1: cpu15

=A0 | |-CORE ID 2: cpu5 cpu17

=A0 | | |-THREAD ID 0: cpu5

= =A0 | | \-THREAD ID 1: cpu17

=A0 | |-CORE I= D 8: cpu7 cpu19

=A0 | | |-THREAD ID 0: cpu7

=A0 | | \-THREAD ID 1: cpu19

= =A0 | |-CORE ID 9: cpu9 cpu21

=A0 | | |-THR= EAD ID 0: cpu9

=A0 | | \-THREAD ID 1: cpu21

=A0 | \-CORE ID 10: cpu11 cpu23

=A0 | =A0 |-THREAD ID 0: cpu11

=A0 | =A0 = \-THREAD ID 1: cpu23

=A0 \-CHIP ID 1: cpu0 cpu2 cpu4 cpu6 cpu8 cpu10 = cpu12 cpu14 cpu16 cpu18 cpu20 cpu22

=A0 =A0= |-CORE ID 0: cpu0 cpu12

=A0 =A0 | |-THREAD= ID 0: cpu0

=A0 =A0 | \-THREAD ID 1: cpu12

=A0 =A0 |-CORE ID 1: cpu2 cpu14

=A0 =A0 | |-THREAD ID 0: cpu2

=A0 =A0= | \-THREAD ID 1: cpu14

=A0 =A0 |-CORE ID 2: cpu4 cpu16

=A0 =A0 | |-THREAD ID 0: cpu4

=A0 =A0 | \-THREAD ID 1: cpu16

=A0 =A0 = |-CORE ID 8: cpu6 cpu18

=A0 =A0 | |-THREAD ID 0: cpu6

=A0 =A0 | \-THREAD ID 1: cpu18

=A0 =A0 |-CORE ID 9: cpu8 cpu20

=A0 =A0 |= |-THREAD ID 0: cpu8

=A0 =A0 | \-THREAD ID 1: cpu20

=A0 =A0 \-CORE ID 10: cpu10 cpu22

=A0 =A0 =A0 |-THREAD ID 0: cpu10

= =A0 =A0 =A0 \-THREAD ID 1: cpu22

And here are some tests. The differences are < 5% (b= ut not so much):

############ enable smt ########

= kern.usched_bsd4.smt_enable: 0 -> 1

tps =3D 53019.868091 (incl= uding connections establishing)

tps =3D 52814.820895 (including connections establishing)

tp= s =3D 53251.869806 (including connections establishing)

tps =3D 5= 3914.301869 (including connections establishing)

tps =3D 53278.85= 8660 (including connections establishing)

tps =3D 53044.933921 (including connections establishing)

tp= s =3D 53758.093953 (including connections establishing)

tps =3D 5= 3965.776254 (including connections establishing)

tps =3D 53093.80= 9461 (including connections establishing)

tps =3D 53322.645105 (including connections establishing)

############ disable smt ########

kern.usched_bsd4.s= mt_enable: 1 -> 0

tps =3D 51379.980647 (including connections = establishing)

tps =3D 50960.834688 (including connections establishing)

tp= s =3D 51336.041880 (including connections establishing)

tps =3D 5= 1311.336021 (including connections establishing)

tps =3D 51227.94= 4502 (including connections establishing)

tps =3D 50828.181685 (including connections establishing)

tp= s =3D 51342.268742 (including connections establishing)

tps =3D 5= 0887.898412 (including connections establishing)

tps =3D 50667.89= 7897 (including connections establishing)

tps =3D 50960.282830 (including connections establishing)

<= div>

On Mon, Jul 23, 2012 at 2:50 PM, Vishesh Yadav <vishesh3y at gmail.com&= gt; wrote:

Hello,

This week I worked on finding and fixing few pending issues, and worked
on IN_MOVED_TO/IN_MOVED_FROM flags. I'm currertly working on binding these two together using cookie parament in inotify_event which I'm
hoping should be completed by today or tomorrow.

Vishesh

On Mon, Jul 16, 2012 at 08:32:00AM +0530, Vishesh Yadav wrote:
> Date: Mon, 16 Jul 2012 08:32:00 +0530
> From: Vishesh Yadav <vishesh= 3y at gmail.com>
> To: kernel at crater.dr= agonflybsd.org
> Subject: Re: [GSoC] inotify and fs indexing service status
>

> Hello,
>
> This week I completed work on IN_CREATE and did some testing on inotif= y
> and found few bugs. IN_CREATE created some new bugs too on which I'= ;m
> currently working on.
>
> Vishesh
>
> On 07/08/2012 09:41 PM, Vishesh Yadav wrote:
> > Hello,
> >
> > This week I worked on NOTE_CREATE and IN_MOVED_* flags. These fla= gs
> > required some workaround as their behavior required a little more=
> > information than what is offered by kevent. There were few more p= roblems
> > with this including the merging of events in kqueue for which I&#= 39;m trying to
> > find a viable solution.
> >
> > Vishesh
> >
> > On Tue, Jul 3, 2012 at 12:10 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
> >
> >> Hello,
> >>
> >> I wasn't able to put much work on code last week. Did som= e work on man
> >> pages.
> >>
> >> Vishesh
> >>
> >>
> >> On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>
> >>> Hello,
> >>>
> >>> In fifth week I implement idr - integer management librar= y using code of
> >>> file descriptor allocators in kern_descrip.c. Worked to u= se the new library
> >>> to be used with filedesc, however something or other didn= 't work out. Will
> >>> be trying that again after looking at code more properly.= Rest tested
> >>> existing work done till now which seems to work quite fin= e. There are
> >>> mainly two events left to handle IN_MOVED_TO and IN_MOVED= _FROM, which I'm
> >>> being able to detect however have to synchronise them bot= h using cookie
> >>> argument.
> >>>
> >>> Vishesh
> >>>
> >>>
> >>> On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com>wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> This week's status -
> >>>>
> >>>> * Added following notes for EVFILT_VNODE - NOTE_OPEN,= NOTE_ACCESS,
> >>>> NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. Th= ey work with Hammer
> >>>> and UFS.
> >>>>
> >>>> * Implemented inotify_read() and have the most import= ant masks working.
> >>>> Hence now we have a working inotify system.
> >>>>
> >>>> Vishesh
> >>>>
> >>>> On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Not much new code this week. Improved and tested = existing code, exposed
> >>>>> watch/instance limits through sysctl and made the= system respect the
> >>>> limits.
> >>>>>
> >>>>> Rest studied kernel kqueue interface and its usag= e to be used in
> >>>>> inotify_read. Planned to add few knotes like NOTE= _ACCESS, NOTE_CLOSE
> >>>> and
> >>>>> linux like idr integer management that can be use= d in fdalloc and watch
> >>>>> descriptors.
> >>>>>
> >>>>> Regards,
> >>>>> Vishesh
> >>>>>
> >>>>> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This week I finished watch management functio= ns. Now watches can be
> >>>> added,
> >>>>>> removed from into the inotify_instance. Hence= inotify_add_watch,
> >>>>>> inotify_rm_watch are now almost complete. Jus= t have to check error
> >>>> codes
> >>>>>> that are being returned. I also implemented f= o_close for inotify
> >>>> fileops
> >>>>>> which cleans up the instance well now.
> >>>>>>
> >>>>>> Regards,
> >>>>>> Vishesh
> >>>>>>
> >>>>>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yada= v <vishesh3y at gmail.com> > >>>> wrote:
> >>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>> Current status for first week -
> >>>>>>>
> >>>>>>> - Repository and wiki setup at Github[1]<= br> > >>>>>>> - Made the basic skeleton for inotify int= erface - system calls,
> >>>> helper
> >>>>>>> functions, structures, headers and few ba= sic stuff in there.
> >>>>>>> - Currently working on management of watc= hes (will be using separate
> >>>>>>> file tables for watches). Once this is do= ne, can write some working
> >>>> code.
> >>>>>>>
> >>>>>>> In community bonding period, I setup my w= orking environment, browse
> >>>> and
> >>>>>>> understood relevant kernel codebase and s= tudied Linux early and
> >>>> recent
> >>>>>>> inotify implementation.
> >>>>>>>
> >>>>>>> Now that exams are almost over, I hope I = can catch up some pace now.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Vishesh
> >>>>>>>
> >>>>>>> [1] https://github.com/vishesh/DragonFlyBSD/<= /a>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>

--
=A0 =A0 =A0 =A0 -Vishesh

I fixed the bugs regarding the CPU Topology on monster (her= e [1] you have the cpu topology sysctl output from the monster). There were= multiple problems:

- one bug that I introduced when I did the re= factoring in order to add support for cpu topology to the vkernel

- I considered that the APICIDs are starting from 0 (in this case the = APICIDs were starting from 16)

PS: Matthew thanks a lot for the monster. You can shut = it down now:). I don't have any heuristics for core/chip cache coherenc= e right now to do performance testing.

[1]=A0 http://lea= f.dragonflybsd.org/~mihaic/monster_cpu_topology

[2]=A0https://github.com/mihaicarabas/drago= nfly/commit/5834c4f987284ba4f395ae701a64f3985ffc7490

On Tu= e, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com><= /span> wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mon, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Tue, Jul 3, 2012 at 12:10 = PM, Vishesh Yadav <vishesh3y at gmail.com> wrote:
Hello,

I wasn't able to put much work on code last week. Did som= e work on man pages.

= Vishesh

On Tue, Jun 26, 2012 at 10:13 AM, Vishesh Yadav <vishesh3y at gmail.com= > wrote:

Hello,

In fifth week I implement idr = - integer management library using code of file descriptor allocators in ke= rn_descrip.c. Worked to use the new library to be used with filedesc, howev= er something or other didn't work out. Will be trying that again after = looking at code more properly. Rest tested existing work done till now whic= h seems to work quite fine. There are mainly two events left to handle IN_M= OVED_TO and IN_MOVED_FROM, which I'm being able to detect however have = to synchronise them both using cookie argument.

Vishesh

On Mo= n, Jun 18, 2012 at 2:54 AM, Vishesh Yadav <vishesh3y at gmail.com> wrote:

Hello,

This week's status -

* Added following notes for EVFILT_VNODE - NOTE_OPEN, NOTE_ACCESS,
NOTE_CLOSE_WRITE, NOTE_CLOSE_NOWRITE, NOTE_CREATE. They work with Hammer and UFS.

* Implemented inotify_read() and have the most important masks working.
Hence now we have a working inotify system.

Vishesh

On 06/10/2012 11:42 PM, Vishesh Yadav wrote:
> Hello,
>
> Not much new code this week. Improved and tested existing code, expose= d
> watch/instance limits through sysctl and made the system respect the l= imits.
>
> Rest studied kernel kqueue interface and its usage to be used in
> inotify_read. Planned to add few knotes like NOTE_ACCESS, NOTE_CLOSE a= nd
> linux like idr integer management that can be used in fdalloc and watc= h
> descriptors.
>
> Regards,
> Vishesh
>
> On 06/03/2012 10:14 PM, Vishesh Yadav wrote:
>> Hello,
>>
>> This week I finished watch management functions. Now watches can b= e added,
>> removed from into the inotify_instance. Hence inotify_add_watch, >> inotify_rm_watch are now almost complete. Just have to check error= codes
>> that are being returned. I also implemented fo_close for inotify f= ileops
>> which cleans up the instance well now.
>>
>> Regards,
>> Vishesh
>>
>> On Sat, May 26, 2012 at 7:07 PM, Vishesh Yadav <vishesh3y at gmail.com> wrote= :
>>
>>> Hello everyone,
>>>
>>> Current status for first week -
>>>
>>> - Repository and wiki setup at Github[1]
>>> - Made the basic skeleton for inotify interface - system calls= , helper
>>> functions, structures, headers and few basic stuff in there. >>> - Currently working on management of watches (will be using se= parate
>>> file tables for watches). Once this is done, can write some wo= rking code.
>>>
>>> In community bonding period, I setup my working environment, b= rowse and
>>> understood relevant kernel codebase and studied Linux early an= d recent
>>> inotify implementation.
>>>
>>> Now that exams are almost over, I hope I can catch up some pac= e now.
>>>
>>> Regards,
>>> Vishesh
>>>
>>> [1] https://github.com/vishesh/DragonFlyBSD/
>>>
>>
>
>

On Sun, Jul 8, 2012 at 12:29 PM, M= ihai Carabas <mihai.carabas at gmail.com> wrote:
Hello,

=A0

In your AES GCM implementation, you have the follow= ing lines of code in cryptosoft.c, in fucntion swcr_combined():

<= br>

*******

=A0=A0for (crd =3D crp->crp_desc; crd; c= rd =3D crd->crd_next) {

for = (sw =3D swcr_sessions[crp->crp_sid & 0xffffffff];

=A0 =A0 sw &= & sw->sw_alg !=3D crd->crd_alg;

=A0= =A0 sw =3D sw->sw_next)

;

if (sw =3D=3D NULL)

ret= urn (EINVAL);

switch (sw->sw_alg) {

case CRYPTO_AES_GCM= _16:

case= CRYPTO_AES_GMAC:

swe =3D sw;

crde =3D crd;

exf= =3D swe->sw_exf;

ivlen =3D exf->blocksize;

break;

case= CRYPTO_AES_128_GMAC:

case CRYPTO_AES_192_GMAC:

case CRYPTO_AES_256_GMAC:=

swa= =3D sw;

crda =3D crd;

axf =3D swa->sw_axf;

if = (swa->sw_ictx =3D=3D 0)

return (EINVAL);

bcopy(swa->sw_ictx, &= amp;ctx, axf->ctxsize);

blk= sz =3D axf->blocksize;

break;

default:

ret= urn (EINVAL);

}

if (crde =3D=3D NULL || crda =3D=3D NULL)

re= turn (EINVAL);

*******

Chris

--e89a8ff1bf64a8054e04c50836de-- From ftigeot at wolfpond.org Tue Jul 17 23:44:33 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 08:44:33 +0200 Subject: Quota on tmpfs Message-ID: On Tue, Jul 17, 2012 at 08:15:20AM -0400, Thor Lancelot Simon wrote: > > In the case of the sparse file, the user has explicitly taken actions > that -- on normal Unix systems and filesystems -- reduce the space > required to store the file. If I open a file and lseek() 1TB off > the end, I have a reasonable expectation to be charged for zero bytes > of storage, or perhaps the size of the inode -- not 1,000,000,000,000 > bytes of storage. The DragonFly VFS quota project was originally an existing Google Summer of Code proposal from 2010. I clearly remember some discussions about sparse files, and a preference beeing made about counting the seek size and not the number of actual blocks used. > However, it is not the case AFAICT that opening a file and seeking > 1TB off the end causes 1TB of allocation in HAMMER. Nor would I expect > the HAMMER maintainers to think such a behavior was desirable; as far > as I can tell they have more sense than that. HAMMER behaves in the same way as UFS, nothing changes here. > > Having a quota system based on visible file sizes gives at least consistent > > results with what a regular user sees when listing files or using du(1). > > You can say that because you avoid mentioning stat(2) or stat(1) or > (at least, not explicitly) ls(1), all of which do actually expose the > difference between the user's requested file length (st_size) and the > block allocations performed on behalf of the user (st_blocks * st_blksize). > > The problem is that you're mixing up apples and oranges: what the filesystem > (HAMMER) or storage device (deduplication) do behind the user's back which > may reduce or increase actual block usage on the underlying storage device > are fundamentally different from what the user expressly requests the > system do to manage block allocation (intentionally creating holes in files). > > Creating an inconsistency between what stat(2) reports and what is charged > against the user's quota really seems like a very bad idea. I understand > that you are trying to simplify away what looks to you like annoying > complexity, but consider the famous Einstein quote: "as simple as possible, > but no simpler". You've gone too simple: your scheme breaks user and > application expectations with regard to behavior the user/application > expressly requested from the kernel. Not a good thing. > > Existing applications reasonably expect that regardless of how much > disk space is available, they can lseek off the end of an existing > file and not get back an error. In fact, EDQUOT is not among the > documented error values for lseek(2) so applications will not > handle it (for the record, lseek also cannot return EFBIG nor ENOSPC). > So you can be pretty sure you will break a good number of existing > Unix applications, likely in data-corrupting ways! As far as I remember, potential application breakages concerns didn't come up when the decision was made to not specially handle sparse files. I may have to it if the first implementation really causes problems in practice. > Again, I am very curious whether you really have consensus from the > other Dragonfly developers in favor of this choice. There was no consensus, but no strong opposition either. Adding kernel@ to the discussion. -- Francois Tigeot From ftigeot at wolfpond.org Tue Jul 17 23:53:24 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 08:53:24 +0200 Subject: Quota on tmpfs Message-ID: On Tue, Jul 17, 2012 at 08:29:10PM +0100, David Laight wrote: > On Tue, Jul 17, 2012 at 01:51:17PM +0200, Francois Tigeot wrote: > > > > Having a quota system based on visible file sizes gives at least consistent > > results with what a regular user sees when listing files or using du(1). > > Ignoring fs metadata is unlikely to be a problem, it is only really > significant for sparse files (and maybe very small ones). > > But you do need to use the 'sparse' size for sparse files. > Many moons ago someone change unixware so that 'ls -s' reported a > value based on the file size - not the number of block used. > Really wasn't a good change at all. > NFI if it got reverted. I'd like to know more about this issue. Are there public records somewhere ? -- Francois Tigeot From ftigeot at wolfpond.org Wed Jul 18 00:18:49 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 09:18:49 +0200 Subject: Quota on tmpfs Message-ID: <846b29a979561b11908474829c7349f5@NO-ID-FOUND.mhonarc.org> On Tue, Jul 17, 2012 at 09:26:44PM -0400, Matthew Mondor wrote: > On Tue, 17 Jul 2012 20:54:28 +0000 (UTC) > mlelstv at serpens.de (Michael van Elst) wrote: > > > I would also guess that sparse files are very rarely used. But for > > disk usage purposes you want to consider real disk usage including > > overhead because the quotas are mostly used to partition the available > > space. That doesn't work if your quotas allow you to write a few > > thousand files of 1 byte length that account together as a single > > single block when they really occupy a few thousand blocks. > > A scenario in which they're frequently used is block-based file system > transfer protocols (especially distributed ones where blocks may > download in random order, including bittorrent), also by download > managers that support "download optimization" where multiple > connections will be made to transfer multiple file sections at a time > (i.e. the DownloadThemAll Firefox extension). > > Another common usage of sparse files is for live file system images. > The cost of creation (open/creat + trunk/lseek + newfs) is small > compared to writing a full image of zeros, then the blocks can be > lazily allocated and written when needed. And this last usage is one good reason to only count seek sizes and not holes in files. Disk quotas can fill up suddenly when data is written to what appears to be a perfectly sized device. The potential for disruption of virtualized systems is very high in this situation and it was deemed best to count the full file size at creation time and avoid bad surprises. -- Francois Tigeot From ahornung at gmail.com Wed Jul 18 03:33:34 2012 From: ahornung at gmail.com (Alex Hornung) Date: Wed, 18 Jul 2012 11:33:34 +0100 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/07/12 09:11, Markus Pfeiffer wrote: > Question is now: Should we have similar functionality (i.e. per > open filedescriptor "private" data) and if yes how to best > implement that. I know that AlexH had made some suggestion but I > cannot find it in the IRC logs and it would probably be more > efficient doing this by mail. My original suggestion, which is straight forward to implement, is to just store the fp in each of the devfs_fo_* operations somewhere (e.g. curthread like FreeBSD, although that isn't all that nice), and then clean it up on devfs_fo_close. Having that, you can easily implement the rest to set up some list or tree or whatever inside a cdev that is also passed to the function. the search key would then be the fp that you stored somewhere whilst in devfs_fo_*. HTH, Alex -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQBpD+AAoJEInr8DonK72KMuEIAIa2/rGQeMivoWj19iFQkbWH 3Qi/bw6HeQ8392B5lG7P5c1eY9zxJCZZnME4vrUGX+IaWepXlZyHfsosFQ6KyiTu K4GIm5HSLBATS9vAgQotZ7yHyExy+m54AZ6C4mXkwK4lU8/5+Gi4wV6D/8lg4Fco pxKjDL9IOXUUQmXvQ6bC5xu8uX8JKuobO3N6LSjJpHwQkHb89fTi2ELh18aOxV6G uh1BBu4AQFtlDC9wGb/5599wAAGTzSDdvzSBkADs4ckhh204xBlNMEQgBT+f1QCf BuEtIgifU10nqMVd9fPbNMzEfC0mCq8JVOsgBrOGqjyZG+1upLNM8QhuokoYO8g= =C91L -----END PGP SIGNATURE----- From ftigeot at wolfpond.org Wed Jul 18 04:53:17 2012 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Wed, 18 Jul 2012 13:53:17 +0200 Subject: devfs_get/set_cdevpriv functions from FreeBSD Message-ID: On Tue, Jul 17, 2012 at 08:11:13AM +0000, Markus Pfeiffer wrote: > > while porting drivers from FreeBSD some of us have stumbled over the functions > devfs_get_cdevpriv and devfs_set_cdevpriv, which store some > per-open-filedescriptor information for some devices. > > I looked into the FreeBSD code and the implementation seems weird to me since > they store the filedescriptor on syscall in their thread struct and the functions > rely on that hidden state. > > Question is now: Should we have similar functionality (i.e. per open > filedescriptor "private" data) and if yes how to best implement that. Have a look at our existing drm infrastructure; there is already some code doing this (a direct replacement of the FreeBSD version). -- Francois Tigeot From tls at panix.com Wed Jul 18 05:10:54 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 08:10:54 -0400 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 08:44:33AM +0200, Francois Tigeot wrote: > > As far as I remember, potential application breakages concerns didn't come > up when the decision was made to not specially handle sparse files. > > I may have to it if the first implementation really causes problems in > practice. > > > Again, I am very curious whether you really have consensus from the > > other Dragonfly developers in favor of this choice. > > There was no consensus, but no strong opposition either. > > Adding kernel@ to the discussion. The other important point that came up yesterday, I think - perhaps more important than mine - is that counting file length rather than allocated blocks allows behaviors that can evade the quota system and fill up the disk. As Michael pointed out, filesystems have a minimum allocation size. For simplicity, let's talk about a FFS filesystem with an 8K block and a 1K fragment. If I open a file and write one byte, under your scheme I am charged for only one byte; but I actually consume 1K of disk space. Do it 1,000 times, and I consume 1MB of space but am charged for only 1K. So both because you can count too much (and break applications that suddenly get impermissible errors from lseek) and count too little (and charge applications for a byte instead of a minimum allocation unit) this seems dubious indeed. Thor From tls at panix.com Wed Jul 18 09:00:25 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 12:00:25 -0400 Subject: Quota on tmpfs Message-ID: <377f84fb72ad1b1710b6aefa5c730faf@NO-ID-FOUND.mhonarc.org> On Wed, Jul 18, 2012 at 11:35:57AM -0400, Mouse wrote: > > So both because you can count too much (and break applications that > > suddenly get impermissible errors from lseek) > > Um, why would anything quota-related ever cause errors from lseek? Because he applies quotas to file length. The lseek is what will take you over quota, whether you ever write or not. Thor From tls at panix.com Wed Jul 18 09:27:05 2012 From: tls at panix.com (Thor Lancelot Simon) Date: Wed, 18 Jul 2012 12:27:05 -0400 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 12:11:10PM -0400, Mouse wrote: > >> Um, why would anything quota-related ever cause errors from lseek? > > Because he applies quotas to file length. The lseek is what will > > take you over quota, whether you ever write or not. > > At least in my experience, lseek never affects any file's size. lseek > such that the file pointer is left past EOF sets it up so a write will > extend the file (with a hole, if far enough past EOF and holes are > supported), but the lseek itself shouldn't do anything to file size. Of course you're right. So the error will come back from write() and applications _should_ handle EDQUOT from write, unless they're written on the assumption nothing but them is ever writing -- but that would not be a good assumption to ever make (I am reminded how C News used to suffer from this). Data corruption should be unlikely but the problem of confounding the application's (and user's) expectations in this case does remain. Thor From dholland-tech at netbsd.org Wed Jul 18 13:39:55 2012 From: dholland-tech at netbsd.org (David Holland) Date: Wed, 18 Jul 2012 20:39:55 +0000 Subject: Quota on tmpfs Message-ID: On Wed, Jul 18, 2012 at 09:18:49AM +0200, Francois Tigeot wrote: > > > I would also guess that sparse files are very rarely used. But for > > > disk usage purposes you want to consider real disk usage including > > > overhead because the quotas are mostly used to partition the available > > > space. That doesn't work if your quotas allow you to write a few > > > thousand files of 1 byte length that account together as a single > > > single block when they really occupy a few thousand blocks. > > > > A scenario in which they're frequently used is block-based file system > > transfer protocols (especially distributed ones where blocks may > > download in random order, including bittorrent), also by download > > managers that support "download optimization" where multiple > > connections will be made to transfer multiple file sections at a time > > (i.e. the DownloadThemAll Firefox extension). > > > > Another common usage of sparse files is for live file system images. > > The cost of creation (open/creat + trunk/lseek + newfs) is small > > compared to writing a full image of zeros, then the blocks can be > > lazily allocated and written when needed. > > And this last usage is one good reason to only count seek sizes and not > holes in files. Disk quotas can fill up suddenly when data is written to > what appears to be a perfectly sized device. > The potential for disruption of virtualized systems is very high in this > situation and it was deemed best to count the full file size at creation > time and avoid bad surprises. It seems like a better way to address that problem would be to provide a scheme to allocate all the blocks in the image files you're concerned about. -- David A. Holland dholland at netbsd.org From ahornung at gmail.com Thu Jul 19 01:14:07 2012 From: ahornung at gmail.com (Alex Hornung) Date: Thu, 19 Jul 2012 09:14:07 +0100 Subject: AES GCM/GMAC Message-ID: Hi, On 17/07/12 16:29, Chris Rogers wrote: > My understanding of GCM and GMAC was that GMAC was an authentication > only variant of GCM, and thus they were mutually exclusive. But, it > looks like the rest of the function will never execute if GMAC isn't > chosen as the mode of encryption. Does this mean that GCM uses GMAC as > part of its standard encryption process, or is the encryption for GCM > only implemented somewhere else? Any help on this matter would be > greatly appreciated. GMAC is just a special case of GCM where the plaintext has zero length, and the whole input is in the AAD. GCM encryption is implemented via transforms (xforms) in our opencrypto. it is effectively a special case of AES CTR, as the other bits that are distinct from CTR (the galois field arithmetic that ends up providing authentication) are implemented in our GMAC implementation. So yes, in other words our GCM uses AES CTR combined with GMAC underneath, resulting, effectively, in GCM. HTH, Alex From crogers122 at gmail.com Thu Jul 19 09:54:39 2012 From: crogers122 at gmail.com (Chris Rogers) Date: Thu, 19 Jul 2012 12:54:39 -0400 Subject: More with AES GCM/GMAC Message-ID: --e89a8ff243c1a17c3704c531a204 Content-Type: text/plain; charset=ISO-8859-1 This is in reference to Alex's reply here . So, let's use this scenario. I'm using an IPsec client that chooses AES GCM 16 as its mode of encryption for ESP. It creates a security association (SA) object, and sends that to the kernel via a socket. It is worthy to note that the authentication portion of this SA is null because it is assumed that GCM will inherently ensure integrity. When this SA reaches the kernel, and is processed through xform_esp.c, key.c, and when it finally reaches cryptosoft.c, there's only one session in the swcr_data struct; namely, the one for GCM. When we try to step through the switch statement, we correctly set the following since it sw->sw_alg is recognized as the CRYPTO_AES_GCM_16 case : swe = sw; crde = crd; exf = swe->sw_exf; ivlen = exf->blocksize; However, since there are no more sessions to jump into any of the CRYPTO_AES_*_GMAC cases, we fail to set any of these: swa = sw; crda = crd; axf = swa->sw_axf; if (swa->sw_ictx == 0) return (EINVAL); bcopy(swa->sw_ictx, &ctx, axf->ctxsize); blksz = axf->blocksize; which are needed by the subsequent if statement: if (crde == NULL || crda == NULL) return (EINVAL); Thus, we return from swcr_combined with an error value of 22 for Invalid Arguments. I'm assuming that the native IPsec client on Dragonfly somehow accounts for this, and will correctly initialize a second session to ensure that the GMAC portion is executed. Pfkeyv2.h doesn't have a SADB_X_AALG ID defined for GMAC, so it must only be used for encryption, and yet the GMACs are defined in auth_hash structs. So, my next question is, how is that session created? How do we get the GMAC case to trigger, and lend its portion of the encryption to GCM without specifying it explicitly as an authentication algorithm in the SA (because that creates a whole host of other problems a lot deeper in the kernel)? --e89a8ff243c1a17c3704c531a204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This is in reference to Alex's reply .

So, let= 9;s use this scenario.=A0 I'm using an IPsec client that chooses AES GC= M 16 as its mode of encryption for ESP.=A0 It creates a security associatio= n (SA) object, and sends that to the kernel via a socket.=A0 It is worthy t= o note that the authentication portion of this SA is null because it is ass= umed that GCM will inherently ensure integrity.=A0 When this SA reaches the= kernel, and is processed through xform_esp.c, key.c, and when it finally r= eaches cryptosoft.c, there's only one session in the swcr_data struct; = namely, the one for GCM.=A0 When we try to step through the switch statemen= t, we correctly set the following since it sw->sw_alg is recognized as t= he CRYPTO_AES_GCM_16 case :

swe =3D sw;
crde =3D crd;
exf =3D swe->sw_exf;
ivlen =3D ex= f->blocksize;

However, since there are no more sessions to jump i= nto any of the CRYPTO_AES_*_GMAC cases, we fail to set any of these: