From owner-freebsd-hackers Sat Apr 19 02:15:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id CAA04428 for hackers-outgoing; Sat, 19 Apr 1997 02:15:22 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA04420 for ; Sat, 19 Apr 1997 02:15:17 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.4/8.8.4) id CAA21092; Sat, 19 Apr 1997 02:15:14 -0700 (PDT) Message-ID: <19970419021513.62962@hydrogen.nike.efn.org> Date: Sat, 19 Apr 1997 02:15:13 -0700 From: John-Mark Gurney To: FreeBSD Hackers Subject: scheduling question... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2-960801-SNAP i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk heh... in the quest to find idprio (I of course didn't know it at the time) I discovered a few things that I found interesting... I was just looking at i386/i386/swtch.s and it looks like we can save a couple clock cycles on processing the real time queue as the real time queue is checked twice, once at line 264, and then again on line 329... sure this isn't much and doesn't get run very often.. (once for each time it handles a real time process)... the fix is REALLY easy too.. :) of course I didn't look to see if the next few instructions will be >128 bytes ahead and cause the jmp to be a larger jmp.. also.. it looks like we have some replicated code that doesn't need to be replicated.. i.e. the dequeuing of the next process... I haven't used gas before but it seems that we could pass in an address to which queue we are manipulating.. and do a generic queue manitpulation and update.. the problem that I see right now is not having a free register in that section of code and that we will suffer from a extra register load (to get the memory location) which will be 2 cycles on a 386, or 1 on a 486... I'm not sure if this would improve performance or not... as the code is probably not cached, only advantage might be not using as many cache lines... also.. it looks like we have a dead jmp in there that does nothing... as it will NEVER be hit.. line 334... comments?? -- John-Mark Cu Networking Modem/FAX: +1 541 683 6954 Live in Peace, destroy Micro$oft, support free software, run FreeBSD