On Tue, Jun 24, 2025 at 3:54 PM Ilya Maximets <[email protected]> wrote:
>
> The 'struct json' contains a union and the largest element of that
> union is 'struct json_array', which takes 24 bytes.  It means, that a
> lot of space in this structure remains unused whenever the type is not
> JSON_ARRAY.
>
> For example, the 'string' pointer used for JSON_STRING only takes 8
> bytes on a 64-bit system leaving 24 - 8 = 16 bytes unused.  There is
> also a 4-byte hole between the 'type' and the 'count'.
>
> A pretty common optimization technique for storing strings is to
> store short ones in place of the pointer and only allocate dynamically
> the larger strings that do not fit.  In our case, we have even larger
> space of 24 bytes to work with.  So, we could use all 24 bytes to
> store the strings (23 string bytes + '\0') and use the 4 byte unused
> space outside the union to store the storage type.
>
> This approach should allow us to save on memory allocation for short
> strings and also save on accesses to them, as the content will fit
> into the same cache line as the 'struct json' itself.
>
> In practice, large OVN databases tend to operate with quite large
> strings.  For example, all the logical flow matches and actions in
> OVN Southbound database would not fit.  However, this approach still
> allows to improve performance with large OVN databases.
>
> With 350MB OVN Northbound database with 12M atoms:
>
>                          Before        After       Improvement
>  ovsdb-client dump      18.6 sec      16.6 sec       10.7 %
>  Compaction             14.0 sec      13.4 sec        4.2 %
>  Memory usage (RSS)     2.28 GB       2.05 GB        10.0 %
>
> With 615MB OVN Southbound database with 23M atoms:
>
>                          Before        After       Improvement
>  ovsdb-client dump      46.1 sec      43.7 sec        5.2 %
>  Compaction             34.8 sec      32.5 sec        6.6 %
>  Memory usage (RSS)     5.29 GB       4.80 GB         9.3 %
>
> In the results above, 'ovsdb-client dump' is measuring how log it
> takes for the server to prepare and send a reply, 'Memory usage (RSS)'
> reflects the RSS of the ovsdb-server after loading the full database.
> ovn-heater tests report similar reduction in CPU and memory usage
> on heavy operations like compaction.
>
> Signed-off-by: Ilya Maximets <[email protected]>


Acked-by: Mike Pattrick <[email protected]>

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to