public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
From: Sven Eckelmann <sven@narfation.org>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: [B.A.T.M.A.N.] [PATCH 0/2] alfred: Use bitmap to store dataset change events
Date: Mon, 24 Jul 2017 23:18:09 +0200	[thread overview]
Message-ID: <13899415.9hl4lahuAs@sven-edge> (raw)

[-- Attachment #1: Type: text/plain, Size: 2053 bytes --]

Hi,

the --update-command implementation looked quite memory inefficient to me and 
I have therefore replaced it using a simple bit map which stores in BIT(i) 
when datatype I was modified. Here from the second patch:

> The implementation for --update-command uses a double linked list to store
> the detected modifications of datasets. This implementation requires 24
> bytes (1 byte data type, 7 bytes padding, 16 bytes linked list pointers) on
> amd64 for each element of the list. Each modified dataset type requires an
> own list item. Each list item is allocated using malloc and therefore
> additional overhead for the libc allocator information has also to be
> stored next to it. The list head uses a similar amount of memory (16 byte
> list pointers, 2 byte counter, 6 byte padding) but doesn't require
> additional allocations.
> 
> The list based implementation provides information about modified dataset
> type and the order in which these modifications were detected. But the
> latter is not actually required fr --update-command and can therefore be
> omitted.
> 
> A simple 256 bit wide storage element (32 bytes) is enough to keep the
> required information when only the detected modified data types have to be
> registered. BIT(i) is either 1 when dataset type i was modified or 0 when
> no modification was detected. This removes the (de)allocation CPU + memory
> overhead and avoids list searches when adding newly detected modifications.

The bitops.h file is used to implement the bit operations and keep the details 
away from the server code. I've reduced the size of the header file a little 
bit because most of it was not used by alfred.

Kind regards,
	Sven

Sven Eckelmann (2):
  alfred: Use constant to define data type range
  alfred: Use bitmap to store dataset change events

 alfred.h |   4 +-
 bitops.h | 379 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 main.c   |   9 +-
 packet.h |   1 +
 server.c |  46 ++++----
 5 files changed, 406 insertions(+), 33 deletions(-)
 create mode 100644 bitops.h

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

             reply	other threads:[~2017-07-24 21:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-24 21:18 Sven Eckelmann [this message]
2017-07-24 21:18 ` [B.A.T.M.A.N.] [PATCH 1/2] alfred: Use constant to define data type range Sven Eckelmann
2017-07-24 21:18 ` [B.A.T.M.A.N.] [PATCH 2/2] alfred: Use bitmap to store dataset change events Sven Eckelmann
2017-07-31  8:57 ` [B.A.T.M.A.N.] [PATCH 0/2] " Simon Wunderlich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13899415.9hl4lahuAs@sven-edge \
    --to=sven@narfation.org \
    --cc=b.a.t.m.a.n@lists.open-mesh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox