NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/sys/next/misc/18751

Internet Message Format | 1992-08-17 | 7.5 KB

Xref: sparky comp.sys.next.misc:18751 comp.sys.next.software:1210
Newsgroups: comp.sys.next.misc,comp.sys.next.software
Path: sparky!uunet!decwrl!mips!darwin.sura.net!Sirius.dfn.de!math.fu-berlin.de!informatik.tu-muenchen.de!meyergru
From: [e-mail] (Uwe Meyer-Gruhl)
Subject: Kernel patches continued... (Was: Ramdisk coming for NeXT)
Keywords: Questions, questions...
References: <[e-mail]> <[e-mail]> <[e-mail]>
Followup-To: comp.sys.next.misc
Sender: [e-mail]
Organization: Technische Universitaet Muenchen, Germany
Date: Tue, 18 Aug 1992 09:13:16 GMT
Message-ID: <[e-mail]>
Lines: 143

Hi folks,

I never thought that this thread I started would gather that much interest.
Several people have asked me questions like:

1. "What are these buffers anyway, doesn't MACH use all available
    memory for buffering?"
2. "How do you know that your number of buffers is _right_,
    i.e.optimal?"
3. "Is it necessary to NOP out the instructions at offset 334079?"
4. "How can I disable remote debugging, as it bothers me not to know
    what can be done to my system's security that way?"
5. "What means kernel flag HZ, BUFPAGES, DSPISR?"

Wow. Kinda curious you guys, aren't you?

1. As I already pointed out, I had the _feeling_ that 16 buffers are
   too little on a system with a capacity of more than 1 GByte. Even
   on a MESS-DOS-PC there is typically a much bigger number of
   buffers involved. Moreover, most users have configured part of
   their memory for a disk cache. O.K., they probably can't use it
   other than that, but I thought that my NeXT would be faster this
   way. Some people second my opinion, they also say that their
   machine are slightly faster.

2. I don't know. Period. I haven't had the time to test all
   varieties. In theory, the more buffers you have, the less likely
   it is for your computer to have to access the harddisk, and
   the faster it is. My HP 9000/700 normally uses 10% of real memory
   for buffers, so I thought this might be a nice point to start.
   There are many parameters involved which can be essential for
   you. Depending on your application, you may need more RAM for
   calculations (e.g. Mathematica), or may want to optimize disk
   accesses (like a database). Maybe you have plenty of RAM (32 MByte
   or even more), so you can sacrifice some of it for buffers, maybe
   not. Or maybe you have a file server which holds a huge amount of
   data which cries for faster access. Maybe you own a 100/8 slab
   and don't need that much buffer space. Matter-of-fact, however,
   the slower the disk, the more effect have buffers (at least from
   what I can tell by comparing, say, a Quantum "slow cat" LP105S and
   a Fujitsu "noisy type" M2624SB).
   Put simply, I have not tested with increasing buffer sizes and
   measured the performance gain. Even if I had, I doubt that the
   results would apply to one of you, since my system configuration
   is rather unusual.

3. I _think_ it is not necessary. The original patch has been
   invented by me after a _few_ tests (see 2.) with "b sd()sdmach
   nbuf=xxx". The instructions at offset 334079 (really 334078)
   disassemble as:

    040516a6    tstl    0x4093814:l    ;Test NBUF value
    040516ac    bnes    0x40516b6    ;if nonzero, go on.
    040516ae    moveq    #16,d3        ;else, choose 16 as
    040516b0    movel    d3,0x4093814:l    ;default and set NBUF
    040516b6    movel    #0x2000,d0    ;code continues here

   Originally, I just patched the #16 into whatever popped into my
   head to set the default. This has the disadvantage that at most
   127 buffers can be used. The instruction is a move _quick_, so the
   value 128 equals -1, which is a _very_ large integer if taken
   unsigned and causes a system panic when mallocing the buffers
   accordingly.
   Later, my friend Christian Baur NOPed out the moveq and movel
   instructions and found out the offset of NBUF in the file.
   I am not quite sure if he had other reasons to both nop out
   these instructions and initialise NBUF to a value other than zero.
   I can assure you that my/his patch works fine, so why bother?
   Marc Albert Ullman (who also wrote binpatch.c, remember?) wrote,
   that he noticed a difference in performance (BTW: better or
   not, Marc?). I can neither neglect nor deny that, since I haven't
   tested it yet.

4. I also wondered how one can disable that feature. I think it
   has been implemented in order to make kernel debugging possible,
   but don't know for sure. Two things one could try are:

   a) Try all "debug" flags. When you startup your next with
      "b sd() sdmach -s" (single-user mode), the debug flag is 0x200,
      as can be seen in the system log (This is from memory,
      so don't blame me). Maybe the remote debugging flag is some
      other bit in that word.
   b) There is a kernel flag named "rmtdebug", which is normally 0.
      It is _more_ likely that setting this flag to some appropriate
      value (e.g. 1?) will disable remote debugging.

   Remember, folks, this is _hacking_, not recipes. You may crash
   your systems by poking around in the kernel! I have not done this
   yet, so I can't tell you how to do it safely. Maybe somebody
   will give it a try and post about the results?

5. Phew. I don't know, either. The list made by Richard "Terminally
   curious" O'Neill is something I had also done to find out the
   names of kernel flags. It seems pretty complete and follows here:

|>   hz phz nbuf bufpages pagesize mem dspicr dspcvr dspisr dspivr
|>   dsph dspm dspl debug maxphys ncallout breakpoint rmtdebug
|>   od_frmr od_land od_spin od_noverify od_maxecc od_maxecc_l1
|>   od_maxecc_h1 od_maxecc_l2 od_maxecc_h2 od_write_retry od_flgstr1
|>   od_flgstr2 mi_rv_delay mi_expire mi_expire_sh mi_expire_sh2
|>   mi_expire_jmp mi_expire_max od_errmsg_filter
|>   od_id_r od_id_v od_id_o od_requested od_dbug init rootdir
|>   rootdev rootrw astune_rate astune_calls
|>

|> I've got little idea which ones one can safely play with, or what
|> they do.  'rootdir', 'rootdev' and 'rootrw' look like they could
|> be useful to some people. 'bufpages' also looks interesting, since
|> it seems related to 'nbuf'.
|>

|> The only one I actually have seen documented is 'mem' (in
|> NeXTanswers, misc.575).
|>

   This goes for me, too. Some of these flags obviously have to do
   with the optical disk (od*). Some seem to be related to the dsp
   (dsp*). I can see little or no benefits from trying to change
   these. HZ is usually a system constant used for clock() and
   similar routines. PHZ seems to be related to HZ. That is all I
   can suspect from the names themselves. I myself will most probably
   _not_ fiddle with those flags any more, as I am curiously awaiting
   NS 3.0, but maybe someone likes to volunteer?

As you may have noted, the answer to most of the questions is: "I
don't know", but aren't they cute, anyway? At the time being, I am
busy getting my doctor's degree, so I can't do everything I would
like to, and deep hacking is one of these things, as it costs time.
>From time to time I change some things that tease me and while
looking at them I see other threads I could follow, but...see above.

Alright. Now I'm going to locate my asbestos suit and wait for the
flames against my "most longish and useless posting ever".

cheers, Uwe

Uwe Meyer-Gruhl                      "Close female relative wear combat boots"
Lehrstuhl Informatik IX
Technische Universitaet Muenchen     email:[e-mail]
Orleansstr. 34, D-8000 Muenchen 80   tel: ++49 89 48095-209