> How can I check whether an Ultra workstation running SunOS 5.7
> uses 64bit features instead of workarounds based on the old
> 32bit functionality? I would like to get an algorithm to
> identify these broken CPUs.
The Solaris 7 kernel runs in either 32- or 64-bit modes on
UltraSPARCs. 64-bit programs only run on 64-bit mode kernels, while
32-bit programs run on either. I don't know what you mean by
"workarounds".
Solaris 7 adds the command "isainfo" to determine the mode of the
running kernel. "isainfo -b" will return either "32" or "64". But
you can't assume much about the CPU based on the result.
By uncommenting one line in a config file, one can run Solaris 7 in
64-bit mode on UltraSPARC I CPUs (the ones with the bug), but to be
safe the default is to run in 32-bit mode on these CPUs. You can also
choose to run Solaris 7 in 32-bit mode on UltraSPARC II CPUs, which
you might want to do if you have some peripheral which doesn't yet
have a 64-bit driver (drivers are all loadable modules in Solaris, and
must match the "bitness" of the kernel).
If your UltraSPARC is <= 200 MHz, it's an UltraSPARC I, and it's
most likely a workstation, where you probably won't benefit much from
64-bit mode in the first place.
Alan Cox wrote:
> > - UFS logging (mount -o logging /dev/dsk/c0t0d0s0 /mnt)
>
> Thats been in for years, I think you just used to pay for it. Its nice
> very nice.
You didn't have to pay for it, but it required a separate partition
for the log. You then mounted a metadevice which combined the file
system partition with the log partition.
With Solaris 7, you just add the mount option "logging" to any UFS
(even one created in previous versions of Solaris) and say goodbye to
Mr. Fsck.
Alan Cox wrote:
>> - TCP performance enhancement with SACK, RFC 2018
> In 2.1.x this is good that Solaris has it too - it really helps with hosts
> that also talk SACK on bad links. It now looks like most non MS OS's will
> be shipping SACK support very soon, and probably MS too.
Actually, Solaris 7 won't currently initiate SACK usage when a
connection is negotiated; the other side must request it. This
behavior can be changed on a running kernel, and the default behavior
may change in a future release.
Dax Kelson wrote:
> - significantly improved paging algorithim, not "on" by default
Actually, it's a subtle change to the existing paging algorithm.
Previously, heavy file system activity (which is basically paging in
Solaris, and therefore obviates the need for a traditional buffer
cache) would cause executables to be paged out, since all pages were
treated equally by the pageout daemon. Now, so long as free RAM
remains above a certain threshold, pages mapped to executable files
aren't freed, which makes the system more responsive during heavy I/O.
This will be the default behavior in future releases if no harmful
side effects are reported.
I miss this behavior after the weekly full backup runs on my
2.1.XXX box, as this causes the apps I left running to have to page
back in before I can use them again, even with 128 MB RAM.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/