Java 1.5 SR 9 JSSE hardware encryption with and without the z90crypt device driver polling thread

JSSE hardware encryption, with Java™ 1.5 SR 9, was studied both with and without the polling thread used for the z90crypt device driver.

The z90crypt device driver at level 2.1.0 and higher provide a configurable polling thread. Starting with Novell SUSE Linux® Enterprise Server (SLES) 10 SP2 and RedHat Enterprise Linux (RHEL) 5.2, the polling thread default setting is disabled. In earlier releases, the polling thread was enabled by default.

The reasons for running with the polling thread enabled are detailed in Variations. For the JSSE workload with 20 concurrent threads, the benefits and costs to packet throughput and CPU utilization are measured with and without the z90crypt polling thread enabled on both the JSSE client and server. Four different ciphers are used with six different packet sizes. The repeated creation, connection, and destruction of SSL connection sockets across the threads is expected to drive high workloads on the IBM® Crypto Express2 feature, because it creates new asymmetric keys for each new connection.

The results are summarized in tabular format in Results tables, tables Table 4, Table 5, and Table 6.

Figure 1 shows the impact on the CPU cost.
Figure 1. Java 1.5 SR9 JSSE hardware encryption with and without polling thread: CEX2A usage
CEX2A usage with and without polling thread

Observations

Enabling the polling thread on both the JSSE client and server provides small gains in throughput on many of the JSSE tests at the expense of additional CPU utilization, particularly on the JSSE server. The comparison of throughput values is derived by calculating a ratio of the normalized throughput values. The CPU comparisons are made using the differences between CPU utilization values.

  • For 2 KB packets on all ciphers, there is an improvement in packet throughput between 10% and 12% when using the polling thread. This improvement comes at the expense of additional CPU utilization, which means a relative increase between 33% and 53% on the JSSE server and approximately 20% on the client.
  • For 20 KB packets using the polling thread, there is:
    • A 10% increase in throughput for ciphers RC4-128 and AES-128
    • A 26% increase in throughput for cipher AES-256
    • A 1% decrease in throughput for cipher 3DES
  • For the larger package sizes, the impact of having the polling thread enabled diminishes. An exception is cipher RC4-128, where the increase of throughput varies from 3% to 13% for the different package sizes, but not consistently.
  • The increase in throughput is mostly related to additional CPU cost for the polling thread. As Figure 1 shows for the server, in most cases there is more throughput from 1% CPU without the polling thread. The client behaves in a similar manner.

Conclusions

It is possible to get approximately a 10% improvement in packet throughput rates using the polling thread up to the 20 KB packet size. This improvement comes at higher CPU cost, which means higher CPU utilization per unit of throughput.

Generally, the use of the polling thread is recommended only where the number of parallel SSL connection threads is less than eight. In these cases, the cryptography load of SSL handshakes on the IBM Crypto Express2 feature adapter in CEX2A mode is rather light. For details, see:

https://www.zjournal.com/printItem.cfm?section=article&aid=1149

When the load on the feature is light, there are often finished encryption requests on the feature that are waiting for a Linux kernel timer event. In these cases, throughput is improved by having an enabled polling thread query the IBM Crypto Express2 feature, so that finished requests can be retrieved and processed without having to wait for the timer event.

From the results of the study, there is at least a slight improvement for most cases when using the polling thread. The best gains in packet throughput come with packets between 2 KB and 20 KB in size, at increasing CPU cost.

If you are running Linux kernel version 2.6.27 or later in an LPAR or with z/VM®, a high-resolution timer is used instead of the standard timer, enabling faster querying of the cryptographic device. AP adapter interrupts are also replacing polling on newer kernel releases on the IBM z10™ EC or later models.