Over time, some entries were unnecessarily complicated.
Entries were sometimes of the form :
Canonical name <canonical@email> first other name <other@mail1>
Canonical name <canonical@email> second other name <other@mail1>
Canonical name <canonical@email> OOops my mailer is wrongly configured <other@mail1>
...
This can be simplified like this :
Canonical name <canonical@email>
Canonical name <canonical@email> <other@mail1>
The added benefit is that we're now exempt of adding a line in .mailmap every time an author make a typo. That will save us time.
Also for name normalisation, a single entry Canonical name <complicated@email> is often enough.
Signed-off-by: Yann Dupont <yann@objoo.org>
Pipe class instance weights over 17 KB in size, and most of it is used by
msgvec structure, which weights 16 KB. Reduce it to 4KB by reducing
number of iovecs in this array down to 256 (= 1024/4). This won't cause
noticeable perf decrease, as even under extreme loads, we exceed 256 used
iovecs in only less than 1% of all write calls. For high-density nodes and
large clusters, savings will exceed hundreds of megabytes per node.
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
AsyncConnection class instance weights over 18 KB in size, and most of it
is used by msgvec structure, which weights 16 KB. Reduce it to 4KB by reducing
number of iovecs in this array down to 256 (= 1024/4). This won't cause
noticeable perf decrease, as even under extreme loads, we exceed 256 used
iovecs in only less than 1% of all write calls. For high-density nodes and
large clusters, savings will exceed hundreds of megabytes per node.
Signed-off-by: Piotr Dałek <piotr.dalek@ts.fujitsu.com>
the boost::icl in boost v1.55 has a bug when working with libc++,
> Assertion failed: (this->_map.find(inter_val) == this->_map.end()),
> function gap_insert, file
> /usr/local/include/boost/icl/interval_base_map.hpp, line 555.
see https://svn.boost.org/trac/boost/ticket/9501 and
https://svn.boost.org/trac/boost/ticket/9987
the bug was fixed in boost v1.56. as a workaround we use the the
`set` from `boost::container` instead of the `std::set` from libc++.
we should drop this workaround once we bump the supported boost
version from 1.42 to 1.56.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Base on current logic, OSDMonitor may call create_pending and
encode_pending twice for the some epoch.
In encode_pending:
tmp.deepish_copy_from(osdmap);
tmp.apply_incremental(pending_inc);
This Op would change the tmp osd_primary_affinity, but the osd_primary_affinity
is declared as ceph::shared_ptr, so this would change the osdmap too. When this
round encode_pending is proposed fail. We may call encode_pending again, but the
osdmap is changed last round, so the pending_inc would be wrong.
Fixes: #14686
Signed-off-by: Xinze Chi <xinze@xsky.com>
it fails to compile with clang, and turns out it should be
`ceph::atomic_t`, but I take this chance to replace it
with std::atomic<> to phase out atomic_t.
Signed-off-by: Kefu Chai <kchai@redhat.com>
its base class 'Dispatcher' is uninitialized when used here to access
'Dispatcher::cct', so we'd better use OSD::cct to initialize it instead.
Signed-off-by: Kefu Chai <kchai@redhat.com>
